Google Cloud

GCP のセキュリティ : クラッシュの自動分析による脆弱性の検出

2017年4月6日

Google Cloud Japan Team

アプリケーションやサーバーがクラッシュしたときは、原因が気になりますよね？クラッシュがセキュリティリスクの兆候なのかどうか、気にかかるのではないでしょうか。

サーバープロセスのクラッシュを適切に処理することは、プラットフォームをハードニングするうえで重要なポイントです。予想外のクラッシュは、サービスに対する攻撃の糸口となるセキュリティ問題の兆候かもしれないからです。信頼性の高いユーザー向けの重要なサービスであっても、クラッシュしたサーバープロセスを使用している可能性があります。

Google では、こうしたクラッシュを収集し、セキュリティに影響を及ぼす可能性のあるものに自動的にフラグを付けて分析しています。

クラッシュに潜むセキュリティ脆弱性

クラッシュ分析はセキュリティ向上のために広く行われています。Google Chrome を使っているときに、クラッシュデータを Google に送信してよいかどうかを尋ねられるのはそのためです。

Google Cloud Platform（GCP）では、顧客データ保護の標準プロセスを使用して、お客様の仮想マシン（VM）やサービス全体を管理するプロセスで発生したクラッシュを監視しています。

クラッシュの原因となるセキュリティ上の問題はさまざまです。なかでも、Use After Free 脆弱性はよく知られている問題です。この脆弱性は、すでに開放されたメモリ領域を使おうとしたときに発生します。

ほとんどの場合、Use After Free 攻撃は単にプログラムをクラッシュさせるだけです。しかし、メモリを適切に操作できる能力を攻撃者が有するときは、この脆弱性を利用して任意のコードを実行されてしまう危険があります。

最近の Use After Free 攻撃の例としては、CVE-2016-5177 があります。このときは、Chrome が使っている V8 JavaScript エンジンの Use After Free 脆弱性が社外の研究者によって発見されています。なお、この問題は Chrome の 2016 年 9 月のリリースで修正されました。

分析の戦術

1 つのクラッシュをデバッグするだけでも大変な手間がかかることがあります。数千ものサーバージョブを管理しなければならないのに、どうすればクラッシュのデバッグをこなせるのでしょうか。

GCP を構成する Google Compute Engine や Google App Engine などのサービスは急速に進化しており、そうした製品のセキュリティを確保するには、クラッシュを引き起こす可能性のある問題を自動的に発見するための手段が必要です。

ちなみに、Compute Engine が登場したばかりの頃は、同時実行中の VM 数が今よりはるかに少なかったため、セキュリティエンジニアが手作業でクラッシュを分析していました。

当時は、gdb にクラッシュダンプをロードし、クラッシュの原因となったスレッドを調べていました。そうすると、クラッシュ直前のプログラムの状態を詳細に把握できるからです。たとえば、実行可能のマークが付けられた領域からプログラムが実行されているかどうかをチェックできます。もし実行されていなければ、セキュリティ上の問題が存在する恐れがあります。

gdb によるクラッシュ分析は非常に効果的でしたが、クラウドのサービスとユーザーが増えるにつれ、このような分析を手作業で行うことは難しくなりました。

分析の自動化

私たちに必要なのは、クラッシュを自動的にチェックする手段でした。Use After Free 脆弱性やその他のセキュリティ問題に対処するためです。そこで、Google 全体のクラッシュデータを集め、一連の兆候をチェックし、修正すべきセキュリティ問題か、さらなる分析が必要かのフラグを付与するシステムを組み込みました。

クラッシュはさまざまな理由で発生します。たとえば、通常のストレステストを実行するだけで何度も起きるクラッシュのように、セキュリティ上の脅威とは無関係なものもあります。そのため、このトリアージの自動化は重要でした。セキュリティ上の問題が見つかったときは、問題の詳細を記録し、悪用される危険度を記したバグレポートが自動的に割り当てられます。