Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Security Response

Android でクラスのロード処理に乗っ取りの脆弱性

Created: 30 Jun 2011 07:49:41 GMT • Translations available: English
Mario Ballano's picture
0 0 Votes
Login to vote

シマンテックでは、最初に出現して以来一貫して Android の脅威を監視し、その解析と分類の方法を模索するとともに、遠からず利用されると予想される感染経路にも注目してきました。Android アプリケーションが、インストールされている他のアプリケーションを悪用して個人情報を盗み出したり悪質なコードを実行したりする経緯も、いくつかの調査で明らかになりました。なかでも、私たちが発見したのは、Windows DLL Hijacking と似たものでした。今回お話ししているのは、Android 自体の脆弱性ではなく、アプリケーション固有の問題であることにご注意ください。Google の Android マーケットプレイスでは、この攻撃を受けやすいアプリケーションが複数見つかっており、そのアプリケーションの開発者にはその旨が通達されています。

Android では、アプリケーションがコードを動的にロードして実行するための API が公開されています。たとえば、ダウンロードしておき、後からロードするプラグインがサポートされているアプリケーションもあります。残念なことに、このようなプラグインが安全でない場所に保存されていると、このプロセスが乗っ取られ、個人データへのアクセスを許したり、悪質なアプリケーションによって任意のコードが実行されたりします。追加のコードのロードを許すクラスは、次の 2 つです。

  パブリックコンストラクタ

DexClassLoader (String dexPath, String dexOutputDir, String libPath, ClassLoader parent)

解釈されたネイティブコードを検索する DexClassLoader を作成します。

PathClassLoader (String path, String libPath, ClassLoader parent)

指定されたファイルとディレクトリの2 つのリストを操作する PathClassLoader を作成します。

1 つ目のクラス DexClassLoader は、アプリケーションが新たな DEX コード(Android の Dalvik 仮想マシンで実行されるコード)をロードして実行することを許可します。dexPath パラメータで、追加される DEX コードのファイル名を指定します。最も顕著な脆弱性が存在するのは、開発者がこの dexPath として自由に書き込み可能なディレクトリ(SD カードなど)を使う場合です。悪質なアプリケーションは、本来の DEX コードを簡単に悪質なコードに置き換えることができます。幸い、大部分の開発者はこの問題を認識しているので、この点で脆弱なアプリケーションは確認されていません。しかし、DEX コードはパフォーマンスを最適化した ODEX(optimized DEX)というバージョンに内部で変換され、この ODEX ファイルが、dexOutputDir パラメータで指定したパスに保存されます。

残念ながら、このパラメータの目的も、ODEX ファイルの用途も理解していない開発者が少なくないようです。オンラインで見られるコード例の多くでも、Android 開発者のドキュメント自体でも、dexOutputDir に SD カードのパスが使われています。SD カードは、WRITE_EXTERNAL_STORAGE パーミッションを持つアプリケーションによって自由に読み書きが可能です。つまり、SD カードに保存されている任意のファイルを他のアプリケーションが読み書きできることになります。アプリケーションが dexOutputDir に SD カードのパスを使用している場合には、悪質なアプリケーションがそのアプリケーションの ODEX ファイルを悪質な ODEX ファイルに置き換えるのも容易です。そうなると、悪質なアプリケーションは脆弱なアプリケーションのコンテキストでコードを実行でき、個人データにアクセスすることも、場合によっては元のアプリケーションで許可されていなかった悪質な処理を実行することも可能になります。この手法を使ってシマンテックでは、Google の Android マーケットプレイスで発見された脆弱なアプリケーションに対する、概念証明のための悪用コードを作成することに成功しました。許可されたパーミッションに便乗し、本来のアプリケーションで許可されていたパーミッションセットを超える処理を実行できることが確認されたのです。

2 つ目のクラス PathClassLoader でも、libPath パラメータに類似の問題がありますが、幸いこれは起こりそうにないことが判明しています。Android は、API の loadLibrary を使うときなどにロードする追加のネイティブライブラリ(.so ファイル、Linux の共有オブジェクトファイル)を検索する際、このパスを使います。通常、これらは安全な Android システムライブラリパスに存在しますが、先に検索されるのは libPath パラメータです(2.2 より前のリリースでは最初に検索されるパスが逆)。

Google の Android マーケットプレイスでシマンテックは、libPath パラメータに SD カードを指定してこの API を使っているアプリケーションをほかにも発見しています。ただし、それらは Linux バイナリであって DEX コードではないため、別のシステムパーミッションが必要になります。特に、マウントされたファイルシステムでネイティブバイナリが実行されないように、外部ストレージがマウントされるときにはデフォルトで noexec フラグが設定されるため、この攻撃経路は役に立たなくなります。したがって、SD カードを指定していた開発者は、このパラメータの目的を理解していなかったことになります。パスをSD カードに設定しても機能しないからです。

Android アプリケーションで追加のコードをロードする際、開発者はロードされるコードと、代替バージョンとして生成されるコードのどちらも安全なディレクトリに保存されることを確認する必要があります。一般的には、アプリケーションのプライベートディレクトリなどです。DexClassLoader が、デフォルトで dexOutputDir をそのように設定すれば理想的でしょう。シマンテックが Google にこれらの問題を報告したところ、Google からは、開発者向けドキュメントを改訂して、安全でない SD カードの場所を使っている記述を削除する、また開発者にも安全なディレクトリを使うよう指導するという回答がありました。

モバイルデバイスのセキュリティについて詳しくは、シマンテックが最近発行したホワイトペーパー『A Window into Mobile Device Security(モバイルデバイスのセキュリティに関する考察)』を参照してください。このホワイトペーパーでは、Apple iOS と Google Android の 2 大プラットフォームで採用されているセキュリティモデルを詳しく探っています。今回のブログとホワイトペーパーのどちらでも指摘しているように、今日広く利用されているモバイルプラットフォームは、大部分がセキュリティを念頭に置いて設計されていますが、現在の態勢では、モバイルデバイスから定期的にアクセスされる重要な企業資産が十分に保護されているとは言えません。

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。