Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

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

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

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

セキュリティ問題の報告

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

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

バグの緊急性判断

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

プロセスの種類

この表では、プロセスの種類の定義について説明します。プロセスの種類は、アプリまたはプロセスの種類、実行されるエリアによって定義できます。この表では、権限が最小から最大までのプロセスを順に示します。

プロセスの種類 種類の定義
制約されたプロセス 極度に制限された SELinux ドメインで実行されるプロセス。
または
通常のアプリより大幅に制限されたプロセス。
非特権プロセス untrusted_app_all 属性を持つ SELinux ドメインで実行される(またはそれと同等の制約を受ける)アプリまたはプロセス。
特権プロセス SELinux の untrusted_app ドメインによって禁止される可能性がある機能を備えたアプリまたはプロセス。
または
サードパーティ アプリが取得できない重要な権限を持つアプリまたはプロセス。
または
トラステッド コンピューティング ベース(TCB)の一部ではない、デバイスの内蔵ハードウェア コンポーネント。
トラステッド コンピューティング ベース(TCB) カーネルの一部であり、カーネルと同じ CPU コンテキストで実行され(デバイス ドライバなど)、カーネルメモリに直接アクセスでき(デバイスのハードウェア コンポーネントなど)、カーネル コンポーネント内にスクリプトを読み込むことができる機能(eBPF など)、ベースバンド プロセッサ、またはカーネルと同等と見なされる少数のユーザー サービス(initueventdvold)の 1 つである機能。
ブートローダー 起動時にデバイスを構成し、Android OS に制御を渡すコンポーネント。
Trusted Execution Environment(TEE) 悪意のあるカーネルからも保護されるように設計されたコンポーネント(TrustZone や Hypervisor など)。
セキュア エレメント(SE) セキュア エレメントの概要で定義されているように、デバイスの他のすべてのコンポーネントと物理的な攻撃から保護されるように設計されたオプションのコンポーネント。

重大度

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

評価 悪用された場合の影響
重大
  • SE によって保護されたデータへの不正アクセス
  • TEE または SE での任意のコード実行
  • 特権プロセス、ブートローダー、TCB での任意のコードのリモート実行
  • リモートでの永続的なサービス拒否攻撃(デバイスが永続的に操作不能になるか、オペレーティング システム全体の再フラッシュまたは出荷時設定へのリセットが必要になる)
  • パッケージ インストール時のユーザー操作要件のリモートでの回避、または同等の動作
  • デベロッパー、セキュリティ、プライバシー設定のユーザー操作要件のリモートでの回避
  • リモートでのセキュアブートの回避
  • 重要なハードウェア コンポーネントが誤動作しないように設計された安全機構(過熱保護など)の回避
  • ローカル セキュアブートの回避
  • コア セキュリティ機能(SELinux、FDE、seccomp など)の完全な回避
  • 非特権プロセスでの任意のコードのリモート実行
  • 特権プロセス、ブートローダー、TCB での任意のコードのローカル実行
  • TEE によって保護されたデータへの不正なアクセス
  • SE に対する攻撃による、安全性の低い実装へのダウングレード
  • パッケージ インストール時のユーザー操作要件のローカルでの回避、または同等の動作
  • 保護されたデータ(特権プロセスに制限されたデータ)へのリモート アクセス
  • ローカルでの永続的なサービス拒否攻撃(デバイスが永続的に操作不能になるか、オペレーティング システム全体の再フラッシュまたは出荷時設定へのリセットが必要になる)
  • ユーザー操作要件のリモートでの回避(通常はユーザーによる操作か許可が必要な機能またはデータへのアクセス)
  • リクエスト元が安全な送信(WEP などの Wi-Fi 暗号化は対象外)を期待している場合に、安全でないネットワーク プロトコル(HTTP や暗号化されていない Bluetooth など)で行われる機密情報の送信
  • ブートローダー、TEE、SE における多重防御または悪用対策技術の一般的な回避
  • アプリデータまたはユーザー プロファイルを相互分離するオペレーティング システム保護の一般的な回避
  • デベロッパー、セキュリティ、プライバシー設定のユーザー操作要件のローカルでの回避
  • 中間者攻撃を可能にする、標準的な Transport Layer Security(TLS)での暗号脆弱性
  • ロック画面の回避
  • デバイス保護機能、出荷時設定へのリセット保護機能、携帯通信会社による制限の回避
  • 緊急サービスへのアクセスを標的とした妨害
  • TEE によって保護されたユーザー操作要件の回避
  • 制約されたプロセスでの任意のコードのリモート実行
  • リモートでの一時的なデバイスのサービス拒否攻撃(リモートでのハングまたは再起動)
  • 非特権プロセスでの任意のコードのローカル実行
  • 特権プロセスまたは TCB における多重防御または悪用対策技術の一般的な回避
  • 制限されたプロセスの制限の回避
  • 保護されていないデータ(通常は任意のローカルでインストールされたアプリからアクセスできるデータ)へのリモート アクセス
  • 保護されたデータ(特権プロセスに制限されたデータ)へのローカル アクセス
  • ユーザー操作要件のローカルでの回避(通常はユーザーによる操作か許可が必要な機能またはデータへのアクセス)
  • 平文の漏洩を可能にする、標準的な(TLS で使用されるプリミティブではない)暗号プリミティブでの暗号脆弱性
  • Wi-Fi の暗号化または認証の回避
  • 制約されたプロセスでの任意のコードのローカル実行
  • 非標準的な使用での暗号脆弱性
  • 非特権プロセスにおけるユーザーレベルの多重防御または悪用対策技術の一般的な回避
セキュリティ影響ほとんどなし(NSI)
  • 1 つ以上の評価修飾子またはバージョン固有のアーキテクチャの変更により影響が緩和され、根底にあるコードの問題は残る可能性はあるものの、実質的な重大度が「低」以下となった脆弱性
  • 使用前に誤った形式のファイルシステムが常に採用 / 暗号化されている場合に、その形式のファイルシステムを必要とする脆弱性。

評価修飾子

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

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

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

リモート攻撃ベクトルでは、アプリのインストールまたはデバイスへの物理的なアクセスなしで、バグが悪用される可能性があります。これには、ウェブページの閲覧、メールの読み取り、SMS メッセージの受信、悪意のあるネットワークへの接続などによってトリガーされるバグが含まれます。Android セキュリティ チームは重大度を評価する目的で、「近接」攻撃ベクトルもリモート攻撃と見なしています。これには、不正な Wi-Fi パケットまたは Bluetooth パケットの送信が要件となるバグなど、物理的にターゲット デバイスの近くにいる攻撃者だけが悪用できるバグが含まれます。Android セキュリティ チームは、NFC ベースの攻撃を近接攻撃、つまりリモート攻撃と見なしています。

ローカル攻撃では、ユーザーがアプリをインストールして実行するか、Instant App の実行に同意してアプリを実行する必要があります。Android セキュリティ チームは、重大度を評価する目的で、物理的攻撃ベクトルもローカル攻撃と見なしています。これには、ロック画面のバグや USB ケーブルの差し込みが要件となるバグなど、デバイスに物理的にアクセスできる攻撃者だけが悪用できるバグが含まれます。USB 接続を必要とする攻撃は、デバイスのロック解除を必要とする場合もそうでない場合も、重大度は同じです。一般的に、USB に接続している間はデバイスのロックが解除されるためです。

Wi-Fi セキュリティ

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

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

生体認証

生体認証は課題の多い分野であり、最良のシステムでさえ近似的な一致によって欺かれる可能性があります。生体認証の重大度の評価においては 2 種類の攻撃が区別され、エンドユーザーに対する実際のリスクを反映することが意図されています。

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

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

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

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

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

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

パートナーへの通知

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

AOSP へのコードのリリース

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

Android アップデートの受信

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

Google サービスの更新

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

その他のリソース

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

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

レポート

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