Android 安全團隊負責管理 Android 平台以及與 Android 設備捆綁的許多核心 Android 應用程序中發現的安全漏洞。
Android 安全團隊通過內部研究發現安全漏洞，並對第三方報告的錯誤做出響應。外部錯誤的來源包括通過漏洞表單報告的問題、已發表和預發表的學術研究、上游開源項目維護者、我們的設備製造商合作夥伴的通知以及在博客或社交媒體上發布的公開披露的問題。
報告安全問題
任何開發者、Android 用戶或安全研究人員都可以通過漏洞表單向 Android 安全團隊通知潛在的安全問題。
標記為安全問題的錯誤在外部不可見，但在評估或解決問題後最終可能會變得可見。如果您計劃提交補丁或兼容性測試套件 (CTS) 測試來解決安全問題，請將其附加到錯誤報告中並等待響應，然後再將代碼上傳到 AOSP。
對錯誤進行分類
處理安全漏洞的首要任務是確定錯誤的嚴重性以及 Android 的哪個組件受到影響。嚴重性決定問題的優先級，組件決定誰修復錯誤、通知誰以及如何將修復部署給用戶。
上下文類型
該表涵蓋了硬件和軟件安全上下文的定義。上下文可以由它通常處理的數據的敏感性或其運行的區域來定義。並非所有安全上下文都適用於所有系統。該表按特權從最低到最高的順序排列。
| 上下文類型 | 類型定義 |
|---|---|
| 受約束的上下文 | 僅提供最少權限的受限執行環境。 例如，受信任的應用程序在沙盒環境中處理不受信任的數據。 |
| 非特權上下文 | 非特權代碼所期望的典型執行環境。 例如，在具有 untrusted_app_all屬性的 SELinux 域中運行的 Android 應用程序。 |
| 特權上下文 | 特權執行環境可以訪問提升的權限、處理多個用戶 PII 和/或維護系統完整性。 例如，具有被 SELinux untrusted_app域禁止的功能或具有privileged|signature權限的 Android 應用程序。 |
| 操作系統內核 | 功能：
|
| 可信硬件基礎 (THB) | 離散硬件組件（通常位於 SoC 上），提供對設備核心用例至關重要的功能（例如蜂窩基帶、DSP、GPU 和 ML 處理器）。 |
| 引導加載程序鏈 | 一個組件，用於在啟動時配置設備，然後將控制權傳遞給 Android 操作系統。 |
| 可信執行環境（TEE） | 旨在保護其免受惡意操作系統內核影響的組件（例如，TrustZone 和虛擬機管理程序，例如 pKVM，可保護虛擬機免受操作系統內核的影響）。 |
| 安全飛地/安全元件 (SE) | 一種可選硬件組件，旨在保護設備免受設備上所有其他組件和物理攻擊的影響，如安全元件簡介中所定義。 這包括某些 Android 設備中存在的 Titan-M 芯片。 |
嚴重性
錯誤的嚴重性通常反映了成功利用錯誤後可能發生的潛在危害。使用以下標準來確定嚴重性。
| 評分 | 成功利用的後果 |
|---|---|
| 批判的 |
|
| 高的 |
|
| 緩和 |
|
| 低的 | |
| 安全影響可忽略不計 (NSI) |
|
評級修正
雖然安全漏洞的嚴重性通常很容易識別，但評級可能會根據情況而變化。
| 原因 | 影響 |
|---|---|
| 需要作為特權上下文運行才能執行攻擊（不適用於 TEE、SE 和 pKVM 等虛擬機管理程序） | -1 嚴重性 |
| 漏洞特定的詳細信息限制了問題的影響 | -1 嚴重性 |
| 生物識別身份驗證繞過，需要直接來自設備所有者的生物識別信息 | -1 嚴重性 |
| 編譯器或平台配置緩解源代碼中的漏洞 | 如果潛在漏洞為中度或更高，則嚴重程度為中度 |
| 需要對設備內部進行物理訪問，並且在設備關閉或開機後尚未解鎖的情況下仍然可以進行 | -1 嚴重性 |
| 需要在設備開啟且之前已解鎖時對設備內部進行物理訪問 | -2 嚴重性 |
| 需要解鎖引導加載程序鏈的本地攻擊 | 不高於低 |
| 需要在設備上當前啟用開發人員模式或任何持久開發人員模式設置的本地攻擊（並且不是開發人員模式本身的錯誤）。 | 不高於低 |
| 如果沒有SELinux域可以在Google提供的SEPolicy下進行操作 | 安全影響可以忽略不計 |
本地、近端、遠程
遠程攻擊向量表明，無需安裝應用程序或無需物理訪問設備即可利用該漏洞。這包括通過瀏覽網頁、閱讀電子郵件、接收短信或連接到敵對網絡可能觸發的錯誤。出於我們的嚴重性評級的目的，我們還將“近端”攻擊向量視為遠程攻擊向量。其中包括只能由物理上靠近目標設備的攻擊者利用的錯誤，例如需要發送格式錯誤的 Wi-Fi 或藍牙數據包的錯誤。我們認為超寬帶 (UWB) 和基於 NFC 的攻擊是近端攻擊，因此是遠程攻擊。
本地攻擊要求受害者通過安裝並運行應用程序或同意運行即時應用程序來運行應用程序。配對的配套設備將被視為本地設備。出於嚴重性評級的目的，Android 安全團隊還將物理攻擊向量視為本地攻擊向量。其中包括只有具有設備物理訪問權限的攻擊者才能利用的錯誤，例如鎖定屏幕中的錯誤或需要插入 USB 電纜的錯誤。
網絡安全
Android 假定所有網絡都是敵對的，並且可能會注入攻擊或監視流量。雖然鏈路層安全（例如 Wi-Fi 加密）可保護設備與其所連接的接入點之間的通信，但它無法保護設備與其所通信的服務器之間的鏈中的其餘鏈路。
相比之下，HTTPS 通常會端到端地保護整個通信，在數據源處對數據進行加密，然後僅在數據到達最終目的地時對其進行解密和驗證。因此，損害鏈路層網絡安全的漏洞的嚴重程度低於 HTTPS/TLS 中的漏洞：僅 Wi-Fi 加密不足以滿足互聯網上的大多數通信需求。
生物識別認證
生物識別身份驗證是一個充滿挑戰的領域，即使是最好的系統也可能會被近似匹配所欺騙（請參閱Android 開發人員博客：Android 11 中的鎖屏和身份驗證改進）。這些嚴重性評級區分兩類攻擊，旨在反映最終用戶的實際風險。
第一類攻擊允許以通用的方式繞過生物識別身份驗證，而無需來自所有者的高質量生物識別數據。例如，如果攻擊者可以將一塊口香糖放在指紋傳感器上，並根據傳感器上留下的殘留物授予對設備的訪問權限，那麼這就是一個可以在任何易受影響的設備上執行的簡單攻擊。它不需要設備所有者的任何知識。鑑於它具有普遍性並且可能影響更多用戶，因此此攻擊獲得完整的嚴重性評級（例如，“高”，表示繞過鎖屏）。
另一類攻擊通常涉及基於設備所有者的演示攻擊工具（欺騙）。有時，這種生物識別信息相對容易獲得（例如，如果某人在社交媒體上的個人資料圖片足以欺騙生物識別身份驗證，那么生物識別繞過將獲得完整的嚴重性評級）。但是，如果攻擊者需要直接從設備所有者那裡獲取生物識別數據（例如，對其面部進行紅外掃描），那麼這就是一個足夠重要的障礙，它限制了受攻擊影響的人數，因此有一個-1修飾符。
SYSTEM_ALERT_WINDOW和竊聽
有關SYSTEM_ALERT_WINDOW和竊聽劫持政策的信息，請參閱 BugHunter University 的不存在安全影響的錯誤頁面的“非安全關鍵屏幕上的竊聽/覆蓋 SYSTEM_ALERT_WINDOW 漏洞”部分。
Android 汽車操作系統中的多用戶安全性
Android 汽車操作系統採用與其他外形規格不同的多用戶安全模型。每個 Android 用戶都旨在由不同的自然人使用。例如，可以將臨時訪客用戶分配給從車主那裡借用車輛的朋友。為了適應此類用例，用戶默認可以訪問使用車輛所需的必要組件，例如 Wi-Fi 和蜂窩網絡設置。
受影響的組件
負責修復錯誤的開發團隊取決於錯誤所在的組件。它可能是 Android 平台的核心組件、原始設備製造商 (OEM) 提供的內核驅動程序或 Pixel 設備上預加載的應用程序之一。
AOSP 代碼中的錯誤已由 Android 工程團隊修復。低嚴重性錯誤、某些組件中的錯誤或已經公開的錯誤可以直接在公開的 AOSP 主分支中修復；否則它們首先會被修復在我們的內部存儲庫中。
該組件也是影響用戶如何獲取更新的一個因素。框架或內核中的錯誤需要每個 OEM 需要推送的無線 (OTA) 固件更新。 Google Play 中發布的應用程序或庫（例如 Gmail、Google Play Services 或 WebView）中的錯誤可以作為 Google Play 的更新發送給 Android 用戶。
通知合作夥伴
當 Android 安全公告中修復了 AOSP 中的安全漏洞時，我們將向 Android 合作夥伴通知問題詳細信息並提供補丁。支持向後移植的版本列表隨著每個新的 Android 版本的變化而變化。請聯繫您的設備製造商以獲取支持的設備列表。
將代碼發佈到 AOSP
如果安全漏洞存在於 AOSP 組件中，則在 OTA 發布給用戶後，修復程序將推送到 AOSP。在通過 OTA 向設備提供修復之前，可以將低嚴重性問題的修復直接提交到 AOSP 主分支。
接收 Android 更新
Android系統的更新一般通過OTA更新包的方式下發到設備。這些更新可能來自生產設備的 OEM 或為設備提供服務的運營商。 Google Pixel 設備更新來自 Google Pixel 團隊，經過運營商技術驗收 (TA) 測試程序。谷歌還發布了可以側面加載到設備的Pixel 工廠圖像。
更新 Google 服務
除了提供安全漏洞補丁外，Android 安全團隊還會審查安全漏洞，以確定是否有其他方法來保護用戶。例如，Google Play 會掃描所有應用程序並刪除任何試圖利用安全漏洞的應用程序。對於從 Google Play 外部安裝的應用程序，具有 Google Play 服務的設備還可以使用驗證應用程序功能來警告用戶可能有害的應用程序。
其他資源
Android 應用程序開發人員信息：https: //developer.android.com
安全信息存在於 Android 開源和開發者網站中。好的起點：
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
報告
有時，Android 安全團隊會發布報告或白皮書。請參閱安全報告了解更多詳細信息。
,Android 安全團隊負責管理 Android 平台以及與 Android 設備捆綁的許多核心 Android 應用程序中發現的安全漏洞。
Android 安全團隊通過內部研究發現安全漏洞，並對第三方報告的錯誤做出響應。外部錯誤的來源包括通過漏洞表單報告的問題、已發表和預發表的學術研究、上游開源項目維護者、我們的設備製造商合作夥伴的通知以及在博客或社交媒體上發布的公開披露的問題。
報告安全問題
任何開發者、Android 用戶或安全研究人員都可以通過漏洞表單向 Android 安全團隊通知潛在的安全問題。
標記為安全問題的錯誤在外部不可見，但在評估或解決問題後最終可能會變得可見。如果您計劃提交補丁或兼容性測試套件 (CTS) 測試來解決安全問題，請將其附加到錯誤報告中並等待響應，然後再將代碼上傳到 AOSP。
對錯誤進行分類
處理安全漏洞的首要任務是確定錯誤的嚴重性以及 Android 的哪個組件受到影響。嚴重性決定問題的優先級，組件決定誰修復錯誤、通知誰以及如何將修復部署給用戶。
上下文類型
該表涵蓋了硬件和軟件安全上下文的定義。上下文可以由它通常處理的數據的敏感性或其運行的區域來定義。並非所有安全上下文都適用於所有系統。該表按特權從最低到最高的順序排列。
| 上下文類型 | 類型定義 |
|---|---|
| 受約束的上下文 | 僅提供最少權限的受限執行環境。 例如，受信任的應用程序在沙盒環境中處理不受信任的數據。 |
| 非特權上下文 | 非特權代碼所期望的典型執行環境。 例如，在具有 untrusted_app_all屬性的 SELinux 域中運行的 Android 應用程序。 |
| 特權上下文 | 特權執行環境可以訪問提升的權限、處理多個用戶 PII 和/或維護系統完整性。 例如，具有被 SELinux untrusted_app域禁止的功能或具有privileged|signature權限的 Android 應用程序。 |
| 操作系統內核 | 功能：
|
| 可信硬件基礎 (THB) | 離散硬件組件（通常位於 SoC 上），提供對設備核心用例至關重要的功能（例如蜂窩基帶、DSP、GPU 和 ML 處理器）。 |
| 引導加載程序鏈 | 一個組件，用於在啟動時配置設備，然後將控制權傳遞給 Android 操作系統。 |
| 可信執行環境（TEE） | 旨在保護其免受惡意操作系統內核影響的組件（例如，TrustZone 和虛擬機管理程序，例如 pKVM，可保護虛擬機免受操作系統內核的影響）。 |
| 安全飛地/安全元件 (SE) | 一種可選硬件組件，旨在保護設備免受設備上所有其他組件和物理攻擊的影響，如安全元件簡介中所定義。 這包括某些 Android 設備中存在的 Titan-M 芯片。 |
嚴重性
錯誤的嚴重性通常反映了成功利用錯誤後可能發生的潛在危害。使用以下標準來確定嚴重性。
| 評分 | 成功利用的後果 |
|---|---|
| 批判的 |
|
| 高的 |
|
| 緩和 |
|
| 低的 | |
| 安全影響可忽略不計 (NSI) |
|
評級修正
雖然安全漏洞的嚴重性通常很容易識別，但評級可能會根據情況而變化。
| 原因 | 影響 |
|---|---|
| 需要作為特權上下文運行才能執行攻擊（不適用於 TEE、SE 和 pKVM 等虛擬機管理程序） | -1 嚴重性 |
| 漏洞特定的詳細信息限制了問題的影響 | -1 嚴重性 |
| 生物識別身份驗證繞過，需要直接來自設備所有者的生物識別信息 | -1 嚴重性 |
| 編譯器或平台配置緩解源代碼中的漏洞 | 如果潛在漏洞為中度或更高，則嚴重程度為中度 |
| 需要對設備內部進行物理訪問，並且在設備關閉或開機後尚未解鎖的情況下仍然可以進行 | -1 嚴重性 |
| 需要在設備開啟且之前已解鎖時對設備內部進行物理訪問 | -2 嚴重性 |
| 需要解鎖引導加載程序鏈的本地攻擊 | 不高於低 |
| 需要在設備上當前啟用開發人員模式或任何持久開發人員模式設置的本地攻擊（並且不是開發人員模式本身的錯誤）。 | 不高於低 |
| 如果沒有SELinux域可以在Google提供的SEPolicy下進行操作 | 安全影響可以忽略不計 |
本地、近端、遠程
遠程攻擊向量表明，無需安裝應用程序或無需物理訪問設備即可利用該漏洞。這包括通過瀏覽網頁、閱讀電子郵件、接收短信或連接到敵對網絡可能觸發的錯誤。出於我們的嚴重性評級的目的，我們還將“近端”攻擊向量視為遠程攻擊向量。其中包括只能由物理上靠近目標設備的攻擊者利用的錯誤，例如需要發送格式錯誤的 Wi-Fi 或藍牙數據包的錯誤。我們認為超寬帶 (UWB) 和基於 NFC 的攻擊是近端攻擊，因此是遠程攻擊。
本地攻擊要求受害者通過安裝並運行應用程序或同意運行即時應用程序來運行應用程序。配對的配套設備將被視為本地設備。出於嚴重性評級的目的，Android 安全團隊還將物理攻擊向量視為本地攻擊向量。其中包括只有具有設備物理訪問權限的攻擊者才能利用的錯誤，例如鎖定屏幕中的錯誤或需要插入 USB 電纜的錯誤。
網絡安全
Android 假定所有網絡都是敵對的，並且可能會注入攻擊或監視流量。雖然鏈路層安全（例如 Wi-Fi 加密）可保護設備與其所連接的接入點之間的通信，但它無法保護設備與其所通信的服務器之間的鏈中的其餘鏈路。
相比之下，HTTPS 通常會端到端地保護整個通信，在數據源處對數據進行加密，然後僅在數據到達最終目的地時對其進行解密和驗證。因此，損害鏈路層網絡安全的漏洞的嚴重程度低於 HTTPS/TLS 中的漏洞：僅 Wi-Fi 加密不足以滿足互聯網上的大多數通信需求。
生物識別認證
生物識別身份驗證是一個充滿挑戰的領域，即使是最好的系統也可能會被近似匹配所欺騙（請參閱Android 開發人員博客：Android 11 中的鎖屏和身份驗證改進）。這些嚴重性評級區分兩類攻擊，旨在反映最終用戶的實際風險。
第一類攻擊允許以通用的方式繞過生物識別身份驗證，而無需來自所有者的高質量生物識別數據。例如，如果攻擊者可以將一塊口香糖放在指紋傳感器上，並根據傳感器上留下的殘留物授予對設備的訪問權限，那麼這就是一個可以在任何易受影響的設備上執行的簡單攻擊。它不需要設備所有者的任何知識。鑑於它具有普遍性並且可能影響更多用戶，因此此攻擊獲得完整的嚴重性評級（例如，“高”，表示繞過鎖屏）。
另一類攻擊通常涉及基於設備所有者的演示攻擊工具（欺騙）。有時，這種生物識別信息相對容易獲得（例如，如果某人在社交媒體上的個人資料圖片足以欺騙生物識別身份驗證，那么生物識別繞過將獲得完整的嚴重性評級）。 But if an attacker would need to acquire biometric data directly from the device owner (for example, an infrared scan of their face), that's a significant enough barrier that it limits the number of people affected by the attack, so there's a -1 modifier.
SYSTEM_ALERT_WINDOW and Tapjacking
For information about our policies regarding SYSTEM_ALERT_WINDOW and tapjacking, see the " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " section of BugHunter University's Bugs with no security impact page.
Multi-user security in Android Automotive OS
Android Automotive OS adopts a multi user security model different from the other form factors. Each Android user is intended to be used by a different physical person. For example, a temporary guest user can be assigned to a friend who borrows the vehicle from the car's owner. To accommodate use cases like this, users by default have access to necessary components needed to use the vehicle, such as Wi-Fi and cellular network settings.
Affected component
The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the preloaded apps on Pixel devices.
Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP main branch; otherwise they're fixed in our internal repositories first.
The component is also a factor in how users get updates. A bug in the framework or kernel requires an over-the-air (OTA) firmware update that each OEM needs to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, or WebView) can be sent to Android users as an update from Google Play.
Notifying partners
When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.
Releasing code to AOSP
If the security bug is in an AOSP component, the fix is pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP main branch before a fix is available to devices through an OTA.
Receiving Android updates
Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Pixel device updates come from the Google Pixel team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Pixel factory images that can be side-loaded to devices.
Updating Google services
In addition to providing patches for security bugs, the Android security team reviews security bugs to determine if there are other ways to protect users. For example, Google Play scans all apps and removes any app that attempts to exploit a security bug. For apps installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about apps that may be potentially harmful.
Other resources
Information for Android app developers: https://developer.android.com
Security information exists throughout the Android Open Source and Developer sites. Good places to start:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Reports
Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.