セキュリティ アップデートとリソース

Android セキュリティ チームは、Android プラットフォームと、Android デバイスに組み込まれている多くのコア Android アプリで発見されたセキュリティ脆弱性を管理します。

Android セキュリティ チームは、内部調査を通じてセキュリティ脆弱性を発見するとともに、第三者から報告されたバグにも対応します。外部のバグの情報源には、脆弱性報告フォームを通じて報告された問題、発表前または発表済の学術研究、アップストリームのオープンソース プロジェクトの管理者、デバイス メーカーからの通知、ブログやソーシャル メディアの投稿により一般公開された問題などが含まれます。

セキュリティに関する問題を報告する

デベロッパー、Android ユーザー、セキュリティ研究者は、脆弱性報告フォームを通じて Android セキュリティ チームに潜在的なセキュリティ問題を通知できます。

セキュリティ問題としてマークされたバグは、外部には公開されませんが、問題が評価または解決された後に公開される場合があります。セキュリティ問題を解決するパッチまたは互換性テストスイート（CTS）テストを提出する場合は、AOSP にコードをアップロードする前に、バグレポートに添付して返信をお待ちください。

バグを選別する

セキュリティ脆弱性を処理する場合、まず、バグの重大度と影響を受ける Android のコンポーネントを特定します。重大度によって問題の優先順位が決まり、コンポーネントによってバグの修正担当者、通知先、修正をユーザーにデプロイする方法が決まります。

コンテキストの種類

次の表では、ハードウェアとソフトウェアのセキュリティ コンテキストの定義を説明します。コンテキストは、主として処理するデータの機密性、またはどの領域で実行されるかによって定義できます。すべてのセキュリティ コンテキストがすべてのシステムに適用されるわけではありません。この表では、権限の低い順に示します。

コンテキストの種類 種類の定義
制約されたコンテキスト 最小限の権限しか付与されていない実行環境。

信頼できないデータをサンドボックス化された環境で処理する、信頼できるアプリケーションなど。
非特権コンテキスト 非特権コードによって想定される一般的な実行環境。

untrusted_app_all 属性を使用して SELinux ドメインで実行する Android アプリなど。
特権コンテキスト 特権実行環境。昇格された権限の利用、複数ユーザーの個人情報の取り扱い、システムの完全性維持などが行われます。

SELinux の untrusted_app ドメインによって禁止される可能性がある機能を備えているか、privileged|signature 権限を利用できる Android アプリなど。
OS のカーネル 以下の機能:
  • カーネルの一部である機能
  • カーネルと同じ CPU コンテキストで実行される機能（デバイス ドライバなど）
  • カーネルメモリに直接アクセスできる機能（デバイスのハードウェア コンポーネントなど）
  • カーネル コンポーネント内にスクリプトを読み込むことができる機能（eBPF など）
  • カーネルと同等と見なされる少数のユーザー サービス（apexd、bpfloader、init、ueventd、vold など）のいずれかである機能
高信頼ハードウェア基盤（THB） 通常は SoC 上にあり、デバイスのコア ユースケースに不可欠な機能（セルラー ベースバンド、DSP、GPU、ML プロセッサなど）を提供する個別のハードウェア コンポーネント。
ブートローダー チェーン 起動時にデバイスを構成し、Android OS に制御を渡すコンポーネント。
高信頼実行環境（TEE） 悪意のある OS カーネルからも保護されるように設計されたコンポーネント（OS カーネルから仮想マシンを保護する TrustZone や、pKVM などのハイパーバイザなど）。
セキュア エンクレーブ / セキュア エレメント（SE） セキュア エレメントの概要で定義されているように、デバイスの他のすべてのコンポーネントと物理的な攻撃から保護されるように設計されたオプションのハードウェア コンポーネント。

一部の Android デバイスに組み込まれている Titan-M チップを含む。

重大度

バグの重大度は、一般的に、バグが悪用された場合に起こりうる潜在的な損害を反映しています。重大度の判定には次の基準を使用します。

評価 悪用された場合の影響
重大
  • TEE または SE での任意のコード実行
  • セキュリティ関連のソフトウェア コンポーネントやハードウェア コンポーネントが誤動作することを防ぐソフトウェアの仕組み（過熱保護など）の回避
  • リモート サービス認証に使用される機密性の高い認証情報へのリモート アクセス（アカウントのパスワードや署名なしトークンなど）
  • ユーザー操作を必要としないモバイル ベースバンドのコンテキスト内での任意のコードのリモート実行（セル無線通信サービスのバグを悪用するなど）
  • 特権コンテキスト、ブートローダー チェーン、THB、OS カーネルでの任意のコードのリモート実行
  • パッケージ インストール時のユーザー操作要件のリモートでの回避、または同等の動作
  • コア デベロッパー、コア セキュリティ、コア プライバシー設定のユーザー操作要件のリモートでの回避
  • リモートでの永続的なサービス拒否攻撃（恒久的、またはオペレーティング システム全体の再適用または出荷時設定へのリセットが必要になる）
  • リモートでのセキュアブートの回避
  • SE によって保護されているデータへの不正アクセス（SE の弱鍵によって有効化されるアクセスなど）
高
  • コア セキュリティ機能（SELinux、FBE、seccomp など）の完全な回避
  • ブートローダー チェーン、TEE、SE における多層防御または悪用対策技術の一般的な回避
  • アプリ、ユーザー、プロファイルの境界を越えてメモリまたはファイル コンテンツを公開する、オペレーティング システムの保護の一般的な回避
  • SE に対する攻撃による、安全性の低い実装へのダウングレード
  • リモートからアクセス可能な侵害されたベアメタル ファームウェア（ベースバンド、通信プロセッサ（CP）など）からアプリ プロセッサ（AP）カーネルへの切り替え、またはベアメタル ファームウェアを AP カーネルから分離するように設計されたメカニズムの回避
  • デバイス保護機能、出荷時設定へのリセット保護機能、携帯通信会社による制限の回避
  • TEE によって保護されたユーザー操作要件の回避
  • Transport Layer Security（TLS）や Bluetooth（BT）に対する攻撃などのエンドツーエンドのプロトコルに対する攻撃を可能にする暗号脆弱性
  • リモート サービス認証に使用される機密性の高い認証情報へのローカル アクセス（アカウントのパスワードや署名なしトークンなど）
  • 特権コンテキスト、ブートローダー チェーン、THB、OS カーネルでの任意のコードのローカル実行
  • ローカル セキュアブートの回避
  • ロック画面の回避
  • コア デベロッパー、コア セキュリティ、コア プライバシー設定のユーザー操作要件のローカルでの回避
  • パッケージ インストール時のユーザー操作要件のローカルでの回避、または同等の動作
  • ローカルでの永続的なサービス拒否攻撃（恒久的、またはオペレーティング システム全体の再適用または出荷時設定へのリセットが必要になる）
  • 保護されたデータ（つまり特権コンテキストに制限されたデータ）へのリモート アクセス
  • 非特権コンテキストでの任意のコードのリモート実行
  • モバイル サービスまたは Wi-Fi サービスへのアクセスに対するリモートでの妨害のうちユーザー操作を必要としないもの（不正な形式のパケットでセル無線通信サービスをクラッシュさせるなど）
  • ユーザー操作要件のリモートでの回避（ユーザーによる操作か許可が必要な機能またはデータへのアクセス）
  • 緊急サービスへのアクセスを標的とした妨害
  • リクエスト元が安全な送信を期待している場合に、安全でないネットワーク プロトコル（HTTP や暗号化されていない Bluetooth など）で行われる機密情報の送信（WEP などの Wi-Fi 暗号化は対象外）
  • TEE によって保護されたデータへの不正なアクセス（TEE の弱鍵によって有効化されるアクセスなど）
平均
  • 特権コンテキスト、THB、OS カーネルにおける多層防御または悪用対策技術の一般的な回避
  • アプリ、ユーザー、プロファイルの境界をまたいでプロセスの状態やメタデータを明示する、オペレーティング システムの保護の一般的な回避
  • Wi-Fi の暗号化または認証の回避
  • 平文の漏洩を可能にする、標準的な（TLS で使用されるプリミティブではない）暗号プリミティブでの暗号脆弱性
  • 保護されたデータ（つまり特権コンテキストに制限されたデータ）へのローカル アクセス
  • 非特権コンテキストでの任意のコードのローカル実行
  • ユーザー操作要件のローカルでの回避（通常はユーザーによる操作か許可が必要な機能またはデータへのアクセス）
  • 保護されていないデータ（つまりローカルにインストールされたアプリで通常はアクセス可能なデータ）へのリモート アクセス
  • 制約されたコンテキストでの任意のコードのリモート実行
  • リモートでの一時的なデバイスのサービス拒否攻撃（リモートでのハングまたは再起動）
低
  • 非特権コンテキストにおけるユーザーレベルの多層防御または悪用対策技術の一般的な回避
  • 標準的な保護レベルの権限の回避
  • 非標準的な使用での暗号脆弱性
  • デバイス上のパーソナライズ機能（Voice Match や Face Match など）の一般的な回避
  • セキュリティの脆弱性につながる可能性のある間違ったドキュメント
  • 制約されたコンテキストでの任意のコードのローカル実行
  • セキュリティに関する誤った期待を抱かせる、誤解を招く説明を含むシステム定義のテキスト
セキュリティ影響ほとんどなし（NSI）
  • 1 つ以上の評価修飾子またはバージョン固有のアーキテクチャの変更により影響が緩和され、根底にあるコードの問題は残る可能性はあるものの、実質的な重大度が「低」以下となった脆弱性
  • 使用前に不正な形式のファイルシステムが常に採用 / 暗号化されている場合に、その形式のファイルシステムを必要とする脆弱性。
  • ローカルで引き起こされる一時的なサービス拒否攻撃（デバイスを再起動、または攻撃を引き起こしたアプリをアンインストールすることにより、解消できます）。

レート修飾子

セキュリティ脆弱性の重大度は多くの場合容易に特定できますが、評価は状況によって変化します。

理由 効果
攻撃を実行するには、特権コンテキストとして実行する必要がある（TEE、SE、pKVM などのハイパーバイザは該当しない） 重大度 -1
脆弱性固有の詳細により、問題の影響が制限される 重大度 -1
デバイス所有者からの生体認証情報を直接必要とする生体認証情報の回避 重大度 -1
コンパイラまたはプラットフォーム構成によりソースコードの脆弱性が緩和される 根底にある脆弱性が「中」以上の場合、重大度は「中」
デバイス内部に物理的にアクセスする必要があり、デバイスの電源がオフになっているか、電源が入れられてからロックが解除されていない場合でも、アクセスされる可能性がある 重大度 -1
デバイスの電源が入っていてロックが解除されているときにデバイス内部に物理的にアクセスする必要がある 重大度 -2
ブートローダー チェーンのロック解除が必要なローカル攻撃 「低」以下
デバイスで現在デベロッパー モードまたは永続的なデベロッパー モード設定が有効になっている必要があるローカル攻撃（デベロッパー モード自体のバグではない）。 「低」以下
SELinux ドメインが Google 提供の SEPolicy に基づいてオペレーションを実行できない場合 セキュリティ影響ほとんどなし

ローカル、近接、リモート

リモート攻撃ベクトルでは、アプリのインストールまたはデバイスへの物理的なアクセスなしで、バグが悪用される可能性があります。これには、ウェブページの閲覧、メールの読み取り、SMS メッセージの受信、悪意のあるネットワークへの接続などによってトリガーされるバグが含まれます。

近接攻撃ベクトルはリモートと見なされます。これには、不正な Wi-Fi パケットまたは Bluetooth パケットの送信が要件となるバグなど、物理的にターゲット デバイスの近くにいる攻撃者だけが悪用できるバグが含まれます。当チームは超広帯域無線（UWB）攻撃と NFC ベースの攻撃を近接攻撃、つまりリモート攻撃と見なしています。

ローカル攻撃では、攻撃者は被害者に事前にアクセスする必要があります。ソフトウェアのみの架空の例では、被害者がインストールした不正なアプリ、または被害者が実行することに同意した Instant App を通じてアクセスが可能です。

正常にペア設定されたデバイス（Bluetooth 対応デバイスなど）はローカルと見なされます。ペア設定したデバイスとペア設定フローに関与しているデバイスは区別します。

  • ユーザーがペア設定されている他のデバイスを特定する能力（つまり認証）を低下させるバグは近接と見なされるため、リモートです。
  • ペア設定フロー中ではあるものの、ユーザーによる同意（つまり承認）が確立される前に発生するバグは、近接と見なされるため、リモートです。
  • ユーザーの同意が確立した後に発生するバグは、最終的にペア設定に失敗したとしてもローカルと見なされます。

物理攻撃ベクトルはローカルと見なされます。これには、ロック画面のバグや USB ケーブルの差し込みが要件となるバグなど、デバイスに物理的にアクセスできる攻撃者だけが悪用できるバグが含まれます。一般的に、USB に接続している間はデバイスのロックが解除されるため、USB 接続を必要とする攻撃は、デバイスのロック解除を必要とする場合もそうでない場合も、重大度は同じです。

ネットワーク セキュリティ

Android は、すべてのネットワークが悪意を持ち、攻撃の挿入やトラフィックの盗聴を行う可能性があると想定しています。リンクレイヤのセキュリティ（Wi-Fi 暗号化など）は、デバイスとデバイスに接続されているアクセス ポイント間の通信を保護しますが、デバイスとそれが通信するサーバー間のチェーン内の残りのリンクを保護する手段は持っていません。

これとは対照的に、HTTPS は通常、通信全体をエンドツーエンドで保護し、データをそのソースで暗号化した後、最終的な宛先に到達したときに復号して検証します。したがって、リンクレイヤ ネットワークのセキュリティが侵害される脆弱性は、HTTPS / TLS の脆弱性よりも重大度が低いと評価されます。インターネット上のほとんどの通信で、Wi-Fi 暗号化だけでは不十分です。

生体認証

生体認証は課題の多い分野であり、最良のシステムでさえ近似的な一致によって欺かれる可能性があります（詳しくは、Android デベロッパー ブログ: Android 11 のロック画面と認証の改善をご覧ください）。生体認証の重大度の評価においては 2 種類の攻撃が区別され、エンドユーザーに対する実際のリスクを反映することが意図されています。

第 1 の種類は、所有者からの高品質の生体認証データなしで、一般化が可能な方法で生体認証を回避できる攻撃です。たとえば、攻撃者が指紋認証センサーの表面にガムを一切れ置いて、センサーに付着した残留物によりデバイスにアクセスできる場合、攻撃を受けやすい任意のデバイスに対して実行できる単純な攻撃となりえます。この攻撃では、デバイスの所有者に関する知識は必要ありません。この攻撃は一般化が可能で、多数のユーザーに影響する可能性があるため、最大の重大度（たとえば、ロック画面の回避に対する「高」）と評価されます。

もう 1 つの種類の攻撃には、デバイス所有者に基づくプレゼンテーション攻撃手段（スプーフィング）が含まれます。生体認証情報は比較的容易に入手できる場合があります（たとえば、ソーシャル メディア上のプロフィール写真で十分に生体認証を回避できる場合、生体認証の回避は最大の重大度と評価されます）。しかし、攻撃者がデバイス所有者から生体認証データを直接入手する必要がある場合は（たとえば顔の赤外線スキャン）、かなり防御が厚く攻撃の影響を受ける人の数が限られるため、-1 の修飾子が付きます。

SYSTEM_ALERT_WINDOW とタップジャック

SYSTEM_ALERT_WINDOW とタップジャッキングに関する当チームのポリシーについては、BugHunter University の「Bugs with no security impact」ページの「Tapjacking/overlay SYSTEM_ALERT_WINDOW vulability of the non-security-Critical screen」をご覧ください。

Android Automotive OS のマルチユーザー セキュリティ

Android Automotive OS は、他のフォーム ファクタとは異なるマルチユーザー セキュリティ モデルを採用しています。各 Android ユーザーは、それぞれ異なる人物によって使用されることが想定されています。たとえば、車の所有者から車両を借りた友だちに、一時的なゲストユーザーを割り当てることが考えられます。このようなユースケースに対応するため、ユーザーは車両の使用に必要なコンポーネント（Wi-Fi やモバイル ネットワーク設定など）にデフォルトでアクセスできます。

影響を受けるコンポーネント

バグの修正を担当する開発チームは、バグが存在するコンポーネントによって異なります。コンポーネントには、Android プラットフォームのコア コンポーネント、相手先ブランド製品製造企業（OEM）提供のカーネル ドライバ、Google Pixel デバイスにプリロードされたアプリなどがあります。

AOSP コードのバグは、Android エンジニアリング チームによって修正されます。重大度の低いバグ、特定のコンポーネントのバグ、すでに一般に知られているバグは、一般公開されている AOSP main ブランチで直接修正される場合があります。それ以外のバグは、最初に内部リポジトリで修正されます。

コンポーネントは、ユーザーがアップデートを入手する際の要素でもあります。フレームワークまたはカーネルのバグの場合は、各 OEM がプッシュする無線（OTA）ファームウェアの更新が必要です。Google Play で公開されているアプリまたはライブラリ（Gmail、Google Play 開発者サービス、WebView など）のバグの場合は、Google Play のアップデートとして Android ユーザーに送信されることがあります。

パートナーに通知する

Android のセキュリティに関する公開情報で AOSP のセキュリティ脆弱性が修正されると、問題の詳細が Android パートナーに通知され、パッチが提供されます。新しい Android リリースごとに、バックポートでサポートされるバージョンのリストが変更されます。サポートされているデバイスの一覧については、デバイスのメーカーにお問い合わせください。

AOSP にコードをリリースする

AOSP コンポーネントにセキュリティ バグがある場合、OTA がユーザーにリリースされた後に修正が AOSP にプッシュされます。OTA を介してデバイスに修正が提供される前に、重大度の低い問題の修正が AOSP main ブランチに直接送信されることもあります。

Android のアップデートの受信

Android システムのアップデートは通常、OTA アップデート パッケージを通じてデバイスに配信されます。これらのアップデートは、デバイスを製造した OEM またはデバイスにサービスを提供している携帯通信会社から配信される場合もあります。Google Pixel デバイスのアップデートは、携帯通信会社の技術受入（TA）テスト手続きを経た後で、Google Pixel チームから提供されます。Google はまた、デバイスにサイドロードできる Google Pixel のファクトリー イメージも公開します。

Google サービスのアップデート

Android セキュリティ チームは、セキュリティ バグのパッチを提供するだけでなく、セキュリティ バグを確認して、ユーザーを保護する方法が他にあるかどうかを判断します。たとえば、Google Play はすべてのアプリをスキャンし、セキュリティ バグの悪用を試みるアプリをすべて削除します。Google Play 以外からインストールされたアプリの場合、Google Play 開発者サービスがインストールされているデバイスでは、アプリの確認機能を使用して、有害な可能性があるアプリについてユーザーに警告することもできます。

その他のリソース

Android アプリのデベロッパー向けの情報については、https://developer.android.com をご覧ください。

セキュリティ情報については、Android のオープンソースとデベロッパーのサイト全体で提供しています。最初に以下のサイトをご覧ください。

レポート

Android セキュリティ チームは、不定期でレポートやホワイトペーパーを公開しています。詳しくは、セキュリティ レポートをご覧ください。