Androidのセキュリティを強化するためのデータ駆動型アプローチ

私たちは、Androidプラットフォームをすべてのデバイスのすべてのユーザーにとって安全に保つためにあらゆることを行います。セキュリティアップデートは毎月リリースされ   、Vulnerability Rewards Program（VRP）のメンバーによって発見された脆弱性が修正されています  。ただし、コンパイラ を使用してテスト環境を改善するなど、他の潜在的な脆弱性からプラットフォームを保護することも試みてい  ます。 Androidエコシステムにはさまざまな機能を備えたデバイスが含まれているため、すべての決定のバランスを取り、利用可能なデータを考慮に入れる必要があります。



この記事では、特定の状況でセキュリティ制御を選択する方法と、それらを実装する方法について説明します。



Androidを安全に保つには、全体的なアプローチが必要です。潜在的な脆弱性の悪用を困難にするために、複数の原則と手法を使用してデータに基づく意思決定を行います。プラットフォームの強化に関しては、次の質問に答える必要があります。

• 私たちはどのようなデータを持っており、それらはどのように私たちが決定を下すのに役立ちますか？
• どのような攻撃防止ツールが利用できますか？どうすれば改善できますか？どのような状況でそれらを適用する必要がありますか？
• 特定のセキュリティツールを使用すると、どのような問題が発生する可能性がありますか？どのような可能なレイアウトを考慮に入れる必要がありますか？

セキュリティの選択に使用する原則は、Androidプラットフォームのユーザーを保護するための全体的なアプローチを反映しています。

データ主導のセキュリティ決定を行う

特定のソリューションが効果的なプラットフォームコンポーネントを見つけるために、さまざまな情報源に目を向けます。  Androidの脆弱性は、プログラムのリワード （VRP）は、おそらくそれらすべての最も有益です。当社のセキュリティエンジニアは、プログラム参加者によって発見されたすべての脆弱性を分析し、根本原因と重大度レベルを決定します（これらの推奨事項に基づいて  ）。さらに、内部および外部のバグレポートがあります。これらは、脆弱なコンポーネントや、失敗の原因となることが多いコードスニペットを特定するのに役立ちます。そのようなフラグメントがどのように見えるかを知り、それらから生じるエラーの重大度と頻度を理解することで、どのセキュリティ対策が最も効果的であるかについて情報に基づいた決定を下すことができます。





Android Security Bulletins 2019で修正された重大度の高い脆弱性。



ただし、脆弱性レポートだけに依存しないでください。セキュリティの専門家は「ホット」ゾーン、つまり脆弱性がすでに発見されている領域（Stagefrightなど）に注意を払うことが多いため、最初は歪んだ画像を示し  ます。または、すぐに使用できるソリューションを使用して検出しやすい脆弱性を探すこともできます。たとえば、セキュリティ分析ツールがGitHubプラットフォームで公開されている場合、多くの専門家がそれを使用します。



セキュリティの向上に向けた取り組みを均等に分散するよう努めています。私たちのチームは、プラットフォームのあまり探索されておらず、より複雑なコンポーネントに注意を払っています。さらに、自動ファジングテストは、仮想マシンと物理Androidデバイスで継続的に実行されるため、開発の初期段階でバグを見つけて修正できます。使用するツールを決定する際には、発見した問題の根本原因と重大度も分析します。



Android VRPプログラムの一部として、開発者が完全な脆弱性チェーンを追加することをお勧めし  ます攻撃プロセス全体を最初から最後まで追跡できます。原則として、サイバー犯罪者は一度に複数の脆弱性を悪用し、そのようなチェーンではこれらの「バンドル」がはっきりと見えるため、非常に有益です。当社のセキュリティエンジニアは、チェーン全体とその個々のリンクの両方を分析し、チェーン内の新しい攻撃戦略を発見しようとします。この分析は、脆弱性の連続的な悪用を防ぐための戦略（たとえば、ランダムアドレス空間の割り当て や制御フローの整合性メソッド  ）を決定するのに役立ち  、プロセスがリソースへの不要なアクセスを取得した場合に攻撃を軽減できるかどうかも理解します。



明らかに、いくつかの脆弱性は一度に複数のチェーンに含まれる可能性があり、異なる順序で配置されます。したがって、「多層防御」を使用して、個々の脆弱性の有効性を減らし、エクスプロイトの連鎖を長くすることをお勧めします。この場合、攻撃者が効果的なチェーンを構築して攻撃を行うことはより困難になります。



現在のセキュリティの脅威を理解し、将来の傾向を予測するには、特にセキュリティコミュニティの動向を常に把握しておく必要があります。

• サードパーティのセキュリティ専門家と緊密に連携します。
• テーマ別の出版物を読み、会議に出席します。
• マルウェアが使用するテクノロジーを研究する。
• セキュリティの分野における最新の開発を追跡します。
• KSPP、syzbot、LLVM、Rustなどのサイドプロジェクトに参加します 。

その結果、全体的なセキュリティ戦略、既存のソリューションの有効性、および改善の機会についての理解が深まります。

より強力な保護が必要な理由

保護の強化と攻撃の防止

データを分析することで、効果的な攻撃の軽減によってクラス全体の脆弱性に対処できる領域を特定できます。たとえば、プラットフォームの一部のコンポーネントで整数オーバーフローエラーが原因で多くの脆弱性が発生する場合は、整数オーバーフローサニタイザーなどの不特定の動作サニタイザー（UBSan）を使用する必要があります 。メモリアクセスの脆弱性が一般的である場合は  、メモリオーバーフローと使用後の脆弱性に耐性のある強化されたメモリアロケータ （Android 11ではデフォルトで  有効）と攻撃防止ツール（  Control Flow Integrityなど）を使用する必要があります。無料。



データの使用について説明する前に、プラットフォームのセキュリティを強化するためのツールの分類を提案します。これらのツールすべてを分類できる主なセグメントは次のとおりです（ただし、一部のツールと方法は、それらのいくつかに一度に適用される場合があります）。

• エクスプロイト除去ツール
  • 確定的なランタイム修復ツールは 、未定義または不要な動作を検出し、プログラムの実行を中断します。これにより、メモリ内のデータ破損が排除され、軽微な障害のみが発生する可能性が維持されます。多くの場合、このようなツールは点ごとに適用できますが、個々のエラー用に設計されているため、引き続き効果的です。例： 整数オーバーフローサニタイザー と BoundsSanitizer。
  •   . . . . , . : , Control Flow Integrity (CFI), , .
  •  , . ,   . : .
• • . , . , .
• • , . , ( / ). , . :  Android,  Unix,  Linux, SELinux  Seccomp.
• • C C++, Java, Kotlin Rust, . ,    Android  , : C/C++ .

特定の問題に応じて、説明されているツールのどれをどのように使用するかを決定します。たとえば、信頼性の低いデータの処理や複雑な解析を含む大規模なプロセスを扱う場合は、それぞれが適しています。マルチメディアプラットフォームは、アーキテクチャの分解を使用してエクスプロイトをより効果的に軽減し、特権の昇格を防ぐ方法の優れたデモンストレーションです。





歴史的文脈におけるアーキテクチャの分解とメディアフレームワークの分離



リモート攻撃のターゲット（NFC、Bluetooth、Wi-Fi、メディアコンテンツ）は、従来、最も深刻な脆弱性に関連付けられているため、セキュリティの強化を優先する必要があります。通常、これらの脆弱性はVRPプログラムで見つかった最も一般的な根本原因によって引き起こされ、最近、それらすべてに消毒剤を追加しました。



攻撃防止ツールは、セキュリティ境界内に設定または常駐するライブラリとプロセス（たとえば、  libbinder、および標準ライブラリ  libui、  libcore、libcutils）に  役立ちます。）、特定のプロセスに関連付けられていないため。ただし、これらのライブラリはシステムの効率的で安定した動作を担当するため、特定の方法を使用する前に、セキュリティが強化されることを真剣に保証する必要があります。



最後に、高レベルの特権を考えると、カーネルを保護することが重要です。すべてのコードベースには異なる特性と機能があるため、それらの脆弱性の可能性は異なります。ここでの主な基準は、安定性とパフォーマンスです。ユーザーの作業を妨げない効果的なセキュリティ対策のみを使用してください。したがって、保護を強化するための最適な戦略を選択する前に、カーネルに関連するすべての利用可能なデータを注意深く分析します。

データ主導のアプローチは、具体的な結果をもたらしました。2015年にStagefrightの脆弱性が発見された後、 Androidメディアプラットフォームにおける他の多数の重大な脆弱性の報告を受け始めました  。問題を複雑にするために、それらの多くはリモートアクセス可能でした。我々が行った  アンドロイドヌガーシステムの大規模な分解をし、  マルチメディアコンポーネントの脆弱性の定着を促進しました。これらの変更のおかげで、2020年には、インターネット経由でアクセスできるマルチメディアプラットフォームの重大な脆弱性の報告はありませんでした。

展開の決定方法

当然のことながら、最も効果的な攻撃防止ツールに焦点を当てることは理にかなっています。それらを特定するために、各ツールがパフォーマンスにどのように影響するか、ツールを展開してサポートするために必要な作業量、およびシステムの安定性に悪影響を与えるかどうかを調べます。

パフォーマンス

攻撃防止ツールを選択するときは、それがデバイスのパフォーマンスにどのように影響するかを理解する必要があります。一部のコンポーネントまたはシステム全体が負荷を処理できない場合、バッテリーの寿命と全体的なパフォーマンスが低下する可能性があります。これは、セキュリティを強化する必要があるエントリーレベルのデバイスに特に当てはまります。したがって、デバイスのパフォーマンスに影響を与えない最も効果的なソリューションを優先します。



パフォーマンスを評価するときは、プロセッサ時間だけでなく、メモリ使用量、コード長、バッテリ寿命、およびインターフェイスのフリーズのケースにも注意を払い  ます。..。ツールがAndroidエコシステム全体で適切に機能していることを確認するには、リストされているパラメーターをエントリーレベルのデバイスでテストすることが特に重要です。



どのコンポーネントに保護対策を適用するかは非常に重要です。たとえば、バインディングはプロセス間通信に最も一般的に使用されます。したがって、過度の負荷は即座にデバイスの動作に影響を与えます。元のレートでフレームのみを処理するメディアプレーヤーの場合、状況は異なります。ビデオ速度が表示速度よりもはるかに速い場合、追加の負荷はそれほど重要ではありません。



ベンチマークを使用して、特定のソリューションのパフォーマンスへの影響を判断します。コンポーネントのベンチマーク結果がない場合は、たとえば、影響を受けるコーデックを呼び出してメディアファイルをデコードすることにより、ベンチマーク結果を取得する必要があります。テストで許容できない負荷が示された場合、いくつかのオプションがあります。

• パフォーマンスに大きな影響を与える機能の攻撃防止を選択的に無効にします。通常、実行時にリソースを消費する関数はごくわずかです。それらに攻撃軽減を適用しないことで、パフォーマンスを維持し、セキュリティへの影響を最大化できます。  これは、メディアコーデックの1つに対するこのアプローチの例です。リスクを排除するために、前述の機能にエラーがないか事前に確認する必要があります。
• 攻撃防止の使用を最適化します。多くの場合、これにはコンパイラの変更が必要です。たとえば、私たちのチームが使用してに切り替え  整数 オーバーフローの 消毒や 境界 消毒を。
• Scudoに組み込まれているヒープの復元力など、一部の攻撃軽減オプションは、  パフォーマンスを向上させるために調整できます。

これらの改善の多くは、LLVM設計の変更を必要とします。その結果、Androidプラットフォームだけでなく、LLVMコミュニティの他のメンバーも勝ちます。

展開とサポート

攻撃防止ツールを選択するときは、セキュリティとパフォーマンスの考慮事項だけでなく、展開と長期的なサポートのコストも考慮する必要があります。

システムの安定運用に対するセキュリティ対策の影響

特定の攻撃防止ツールを誤ってトリガーする可能性があるかどうかを理解することが重要です。たとえば、Boundsサニタイザーがエラーをスローした場合、それは間違いなく拒否されたアクセスです（使用されていない可能性があります）。整数オーバーフローサニタイザーの場合、整数オーバーフローは完全に正常で無害なプロセスであることが多いため、誤検知が発生する可能性があります。



したがって、攻撃防止ツールがシステムの安定性に与える影響を考慮することが重要です。誤検知があったか、実際のセキュリティ脅威があったかは関係ありません。いずれにせよ、ユーザーは不便を感じます。ここでも、どのコンポーネントに1つまたは別のセキュリティ対策を使用する必要があるかを明確に理解する必要があることに注意してください。一部のコンポーネントの障害は、システムの安定性に大きな影響を与えるためです。攻撃防止がメディアコーデックをクラッシュさせた場合、ビデオは単に再生を停止します。ただし、プロセスでエラーが発生した場合  netd



 アップデートをインストールすると、デバイスの電源が入らなくなる場合があります。誤検知によって一部の攻撃防止ツールで問題が発生しない場合でも（たとえば、Boundsサニタイザーの場合のように）、デバイスが安定していることを確認するために広範なテストを実施しています。たとえば、バイアスエラーが1つでも正常にクラッシュしない可能性があり、Boundsサニタイザーがプロセスを中断してシステムの安定性を損ないます。



また、攻撃防止ツールで無効にできるすべてのコンポーネントを事前に特定できるかどうかを理解することも重要です。たとえば、整数オーバーフローサニタイザーの場合、どの整数オーバーフローが意図的（許可）であり、どの整数オーバーフローが脆弱性を引き起こす可能性があるかを判断することが難しいため、広範なテストを行わずにリスクを予測することは非常に困難です。

サポート

攻撃防止ツールの展開で起こりうる問題だけでなく、長期的なサポートの詳細も考慮する必要があります。ツールを既存のシステムと統合し、アクティブ化してデバッグし、デバイスに展開してから、起動後にサービスを提供するのにかかる時間を見積もります。 SELinuxテクノロジーは良い例です。一連のルールを作成するには、多くの時間と労力がかかります。また、このセットは、コードの変更や個々の機能の追加または削除に関係なく、何年も維持する必要があります。



攻撃防止ツールが安定性に与える影響を最小限に抑え、開発者が必要なすべての情報を入手できるように努めています。これらの目標を達成するために、現在のアルゴリズムを改善して誤検知の数を減らし、source.android.comでドキュメントを公開しています  。障害発生時のデバッグを容易にすることで、開発者のメンテナンス負担を軽減できます。たとえば、UBSanサニタイザーのバグを見つけやすくするために、 デフォルトでUBSanの最小ランタイムサポートをAndroidビルドシステムに追加しました  。最初に最小実行時間が  追加されました 特にこの目的のための他のGoogle開発者。整数オーバーフローサニタイザーが原因でプログラムがクラッシュした場合、次のスニペットがSIGABRTエラーメッセージに追加されます。

Abort message: 'ubsan: sub-overflow' 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

このメッセージを見た後、開発者は、障害に関する情報を出力するために診断モードを有効にする必要があることを理解し  ます。

frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp:2188:32: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

同時に、SELinuxにはaudit2allowツールがあり、特定のブロックされた操作を許可するルールを提案できます。

adb logcat -d | audit2allow -p policy
 #============= rmt ==============
 allow rmt kmem_device:chr_file { read write };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

audit2allowが常に正しいオプションを提案するとは限りませんが、SELinuxを初めて使用する開発者にとっては非常に役立ちます。

結論

Androidがリリースされるたびに、エコシステム全体を保護する新しいツールが提供され、必要なパフォーマンスと安定性が確保されます。これにはデータ分析が重要な役割を果たします。この記事が、新しい攻撃防止ツールの実装の課題とその対処方法をよりよく理解するのに役立つことを願っています。

---

同僚と作者に感謝します：Kevin Deus、Joel Galenson、Billy Lau、IvanLozano-Androidのセキュリティとプライバシーの専門家。この記事の作成に協力してくれたZviadKardavaとJeffVan DerStupに特に感謝します。