[論文レビュー] BinderCracker: Assessing the Robustness of Android System Services

Huan Feng, Kang G. Shin|arXiv (Cornell University)|Apr 23, 2016

Advanced Malware Detection Techniques参考文献 21被引用数 7

ひとこと要約

BinderCracker は、Binder IPC インターフェースに故意に破損したトランザクションを直接注入することで、Android システムサービスの耐障害性をテストする自動的でパラメータに配慮したファジングフレームワークである。このフレームワークは、6 つの Android バージョンにわたり、100 件を超える以前に未知であった脆弱性を発見した。その中には、リモートコード実行や DoS 攻撃を可能にする深刻な脆弱性も含まれており、クライント側の API 保護があるにもかかわらず、サーバー側の入力検証が広く失敗していることが露呈された。

ABSTRACT

In Android, communications between apps and system services are supported by a transaction-based Inter-Process Communication (IPC) mechanism. Binder, as the cornerstone of this IPC mechanism, separates two communicating parties as client and server. As with any client-server model, the server should not make any assumption on the validity (sanity) of client-side transaction. To our surprise, we find this principle has frequently been overlooked in the implementation of Android system services. In this paper, we demonstrate the prevalence and severity of this vulnerability surface and try to answer why developers keep making this seemingly simple mistake. Specifically, we design and implement BinderCracker, an automatic testing framework that supports parameter-aware fuzzing and has identified more than 100 vulnerabilities in six major versions of Android, including the latest version Android 6.0, Marshmallow. Some of the vulnerabilities have severe security implications, causing privileged code execution or permanent Denial-of-Service (DoS). We analyzed the root causes of these vulnerabilities to find that most of them exist because system service developers only considered exploitations via public APIs. We thus highlight the deficiency of testing only on client-side public APIs and argue for the necessity of testing and protection on the Binder interface - the actual security boundary. Specifically, we discuss the effectiveness and practicality of potential countermeasures, such as precautionary testing and runtime diagnostic.

研究の動機と目的

• クライント側 API の強制による依存に起因する Android システムサービスにおける入力検証脆弱性の広がりと深刻度を調査すること。
• クライント・サーバーアーキテクチャにおける既知のベストプラクティスにもかかわらず、開発者がなぜ繰り返しサーバー側の堅牢性を無視するのかを特定すること。
• Binder IPC トランザクションに対する深く意味的認識を持つファジングを可能にする、自動化されたテストフレームワークの設計および実装。
• 公開されたクライント API に依存するのではなく、セキュリティの真の境界である Binder インターフェースにセキュリティテストと検証を移行すべきであることを提唱すること。
• 従来のブラックボックスファジングと比較して、パラメータに配慮したファジングが、より深い、より深刻な欠陥を効果的に発見できるかどうかを実証すること。

提案手法

• BinderCracker は、Java およびネイティブの両方の Android システムサービスの RPC インターフェースを自動的に発見し、クローリングする。
• 実際のトランザクションを記録・変更することで、実行時におけるリモートオブジェクトハンドルの再構築により意味的妥当性を保持しながら、パラメータに配慮したファジングを実行する。
• Binder トランザクション構造に対する深い理解を持つレプレイエンジンにより、複雑な非基本型データ型の変更が可能であり、スキーマの整合性を維持できる。
• 依存関係の追跡と階層的アンマーシャリングを用いて、高レベルのトランザクション構造を、プリミティブでファジング可能な入力に変換する。
• テストカバレッジを向上させ、ランダムなブラックボックスファジングが見逃すエッジケースを特定するため、部分的に有効な入力の変更をサポートする。
• 攻撃の可視性とクラッシュの原因特定を向上させるために、実行時におけるトランザクションスキーマと送信元メタデータを保持する。

実験結果

リサーチクエスチョン

• RQ1 クライント側 API の信頼に起因する入力検証脆弱性は、Android システムサービスにおいてどれほど広がっているのか？
• RQ2 既知のセキュリティリスクがあるにもかかわらず、なぜ Android システムサービスの開発者は繰り返しサーバー側の入力検証を実装しないのか？
• RQ3 従来のブラックボックスファジングと比較して、パラメータに配慮したファジングは、より深い、より深刻な脆弱性の発見を著しく改善できるのか？
• RQ4 特定された脆弱性の根本原因は何か。また、API セキュリティに関する誤った仮定とどのように関連しているのか？
• RQ5 実行時診断およびスキーマログ記録は、エクスプロイトの可視性と脆弱性分析の効果をどの程度向上させるのか？

主な発見

• BinderCracker は、Android 6.0（Marshmallow）を含む 6 つの主要な Android バージョンにわたり、100 件を超える以前に未知であった脆弱性を特定した。
• 発見された脆弱性の 70% を超えるものが、リモートコード実行または恒久的な DoS 攻撃の対象となり得る。一部の脆弱性は、Android ランタイム全体のクラッシュを引き起こした。
• パラメータに配慮したファジングは、同じ時間枠内で同等のブラックボックスファジングと比較して、7 倍も多くの脆弱性を発見した。
• 大多数の脆弱性の根本原因は、開発者がクライント側 API の強制に依存し、プライベート API やデシリアライゼーション処理が安全または到達不能であると誤って仮定していたことにある。
• 多くの脆弱性は、リモートオブジェクトハンドル、デシリアライズされたデータ、非公開インターフェースに対する健全性チェックの欠如に起因していた。
• このフレームワークは、サーバー側の堅牢性が単に必要であるのではなく、実際には未実装に近い状態であることを示した。また、Binder インターフェースこそが、保護すべき真のセキュリティ境界であることを実証した。