安全更新和資源

Android 安全團隊負責管理 Android 平台以及與 Android 設備捆綁的許多核心 Android 應用程序中發現的安全漏洞。

Android 安全團隊通過內部研究發現安全漏洞,並對第三方報告的錯誤做出響應。外部錯誤的來源包括通過漏洞表單報告的問題、已發表和預發表的學術研究、上游開源項目維護者、我們的設備製造商合作夥伴的通知以及在博客或社交媒體上發布的公開披露的問題。

報告安全問題

任何開發者、Android 用戶或安全研究人員都可以通過漏洞表單向 Android 安全團隊通知潛在的安全問題。

標記為安全問題的錯誤在外部不可見,但在評估或解決問題後最終可能會變得可見。如果您計劃提交補丁或兼容性測試套件 (CTS) 測試來解決安全問題,請將其附加到錯誤報告中並等待響應,然後再將代碼上傳到 AOSP。

對錯誤進行分類

處理安全漏洞的首要任務是確定錯誤的嚴重性以及 Android 的哪個組件受到影響。嚴重性決定問題的優先級,組件決定誰修復錯誤、通知誰以及如何將修復部署給用戶。

上下文類型

該表涵蓋了硬件和軟件安全上下文的定義。上下文可以由它通常處理的數據的敏感性或其運行的區域來定義。並非所有安全上下文都適用於所有系統。該表按特權從最低到最高的順序排列。

上下文類型類型定義
受約束的上下文僅提供最少權限的受限執行環境。

例如,受信任的應用程序在沙盒環境中處理不受信任的數據。
非特權上下文非特權代碼所期望的典型執行環境。

例如,在具有untrusted_app_all屬性的 SELinux 域中運行的 Android 應用程序。
特權上下文特權執行環境可以訪問提升的權限、處理多個用戶 PII 和/或維護系統完整性。

例如,具有被 SELinux untrusted_app域禁止的功能或具有privileged|signature權限的 Android 應用程序。
操作系統內核功能:
  • 是內核的一部分
  • 在與內核相同的 CPU 上下文中運行(例如,設備驅動程序)
  • 可以直接訪問內核內存(例如設備上的硬件組件)
  • 能夠將腳本加載到內核組件中(例如,eBPF)
  • 是少數被視為與內核等效的用戶服務之一(例如apexdbpfloaderinitueventdvold )。
可信硬件基礎 (THB)離散硬件組件(通常位於 SoC 上),提供對設備核心用例至關重要的功能(例如蜂窩基帶、DSP、GPU 和 ML 處理器)。
引導加載程序鏈一個組件,用於在啟動時配置設備,然後將控制權傳遞給 Android 操作系統。
可信執行環境(TEE)旨在保護其免受惡意操作系統內核影響的組件(例如,TrustZone 和虛擬機管理程序,例如 pKVM,可保護虛擬機免受操作系統內核的影響)。
安全飛地/安全元件 (SE)一種可選硬件組件,旨在保護設備免受設備上所有其他組件和物理攻擊的影響,如安全元件簡介中所定義。

這包括某些 Android 設備中存在的 Titan-M 芯片。

嚴重性

錯誤的嚴重性通常反映了成功利用錯誤後可能發生的潛在危害。使用以下標準來確定嚴重性。

評分成功利用的後果
批判的
  • TEE 或 SE 中的任意代碼執行
  • 繞過旨在防止安全相關軟件或硬件組件發生故障的軟件機制(例如熱保護)
  • 遠程訪問用於遠程服務身份驗證的敏感憑據(例如帳戶密碼或不記名令牌)
  • 在蜂窩基帶上下文中遠程執行任意代碼,無需用戶交互(例如,利用蜂窩無線電服務中的錯誤)
  • 在特權上下文、引導加載程序鏈、THB 或操作系統內核中遠程執行任意代碼
  • 遠程繞過軟件包安裝或等效行為的用戶交互要求
  • 遠程繞過核心開發人員、安全或隱私設置的用戶交互要求
  • 遠程持續拒絕服務(永久,需要重新刷新整個操作系統,或恢復出廠設置)
  • 遠程安全啟動繞過
  • 對 SE 保護的數據進行未經授權的訪問,包括通過 SE 中的弱密鑰啟用的訪問。
高的
  • 完全繞過核心安全功能(例如 SELinux、FBE 或seccomp
  • 深度防禦的一般繞過或利用引導加載程序鏈、TEE 或 SE 中的緩解技術
  • 操作系統保護的一般繞過,可跨應用程序、用戶或配置文件邊界洩露內存或文件內容
  • 針對 SE 的攻擊導致降級為安全性較低的實施
  • 繞過設備保護/恢復出廠設置保護/運營商限制
  • 繞過 TEE 保護的用戶交互要求
  • 允許針對端到端協議進行攻擊的加密漏洞,包括針對傳輸層安全 (TLS) 和藍牙 (BT) 的攻擊。
  • 對用於遠程服務身份驗證的敏感憑據(例如帳戶密碼或不記名令牌)的本地訪問
  • 在特權上下文、引導加載程序鏈、THB 或操作系統內核中執行本地任意代碼
  • 本地安全啟動繞過
  • 鎖屏繞過
  • 本地繞過核心開發人員、安全或隱私設置的用戶交互要求
  • 本地繞過軟件包安裝或等效行為的用戶交互要求
  • 本地持續拒絕服務(永久,需要重新刷新整個操作系統,或恢復出廠設置)
  • 遠程訪問受保護的數據(即僅限於特權上下文的數據)
  • 在非特權上下文中遠程執行任意代碼
  • 在沒有用戶交互的情況下遠程阻止對蜂窩或 Wi-Fi 服務的訪問(例如,使用格式錯誤的數據包使蜂窩無線電服務崩潰)
  • 遠程繞過用戶交互要求(訪問需要用戶啟動或用戶許可的功能或數據)
  • 有針對性地阻止獲得緊急服務
  • 當請求者期望安全傳輸時,通過不安全的網絡協議(例如 HTTP 和未加密的藍牙)傳輸敏感信息。請注意,這不適用於 Wi-Fi 加密(例如 WEP)
  • 對受 TEE 保護的數據進行未經授權的訪問,包括通過 TEE 中的弱密鑰啟用的訪問
緩和
  • 在特權上下文、THB 或操作系統內核中一般繞過深度防禦或利用緩解技術
  • 操作系統保護的一般繞過,可跨應用程序、用戶或配置文件邊界顯示進程狀態或元數據
  • 繞過 Wi-Fi 加密或身份驗證
  • 標準加密原語中的加密漏洞允許洩露明文(不是 TLS 中使用的原語)
  • 對受保護數據的本地訪問(即僅限於特權上下文的數據)
  • 在非特權上下文中執行本地任意代碼
  • 本地繞過用戶交互要求(訪問通常需要用戶啟動或用戶許可的功能或數據)
  • 遠程訪問未受保護的數據(即通常可由任何本地安裝的應用程序訪問的數據)
  • 在受限上下文中遠程執行任意代碼
  • 遠程臨時設備拒絕服務(遠程掛起或重新啟動)
低的
  • 一般繞過用戶級深度防禦或在非特權環境中利用緩解技術
  • 繞過正常保護級別權限
  • 非標準使用中的加密漏洞
  • 一般繞過設備上的個性化功能,例如語音匹配面部匹配
  • 不正確的文檔可能會導致安全漏洞
  • 在受限上下文中執行本地任意代碼
  • 系統定義的文本,其中包含誤導性描述,會產生錯誤的安全期望
安全影響可忽略不計 (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 開源和開發者網站中。好的起點:

報告

有時,Android 安全團隊會發布報告或白皮書。請參閱安全報告了解更多詳細信息。

,

Android 安全團隊負責管理 Android 平台以及與 Android 設備捆綁的許多核心 Android 應用程序中發現的安全漏洞。

Android 安全團隊通過內部研究發現安全漏洞,並對第三方報告的錯誤做出響應。外部錯誤的來源包括通過漏洞表單報告的問題、已發表和預發表的學術研究、上游開源項目維護者、我們的設備製造商合作夥伴的通知以及在博客或社交媒體上發布的公開披露的問題。

報告安全問題

任何開發者、Android 用戶或安全研究人員都可以通過漏洞表單向 Android 安全團隊通知潛在的安全問題。

標記為安全問題的錯誤在外部不可見,但在評估或解決問題後最終可能會變得可見。如果您計劃提交補丁或兼容性測試套件 (CTS) 測試來解決安全問題,請將其附加到錯誤報告中並等待響應,然後再將代碼上傳到 AOSP。

對錯誤進行分類

處理安全漏洞的首要任務是確定錯誤的嚴重性以及 Android 的哪個組件受到影響。嚴重性決定問題的優先級,組件決定誰修復錯誤、通知誰以及如何將修復部署給用戶。

上下文類型

該表涵蓋了硬件和軟件安全上下文的定義。上下文可以由它通常處理的數據的敏感性或其運行的區域來定義。並非所有安全上下文都適用於所有系統。該表按特權從最低到最高的順序排列。

上下文類型類型定義
受約束的上下文僅提供最少權限的受限執行環境。

例如,受信任的應用程序在沙盒環境中處理不受信任的數據。
非特權上下文非特權代碼所期望的典型執行環境。

例如,在具有untrusted_app_all屬性的 SELinux 域中運行的 Android 應用程序。
特權上下文特權執行環境可以訪問提升的權限、處理多個用戶 PII 和/或維護系統完整性。

例如,具有被 SELinux untrusted_app域禁止的功能或具有privileged|signature權限的 Android 應用程序。
操作系統內核功能:
  • 是內核的一部分
  • 在與內核相同的 CPU 上下文中運行(例如,設備驅動程序)
  • 可以直接訪問內核內存(例如設備上的硬件組件)
  • 能夠將腳本加載到內核組件中(例如,eBPF)
  • 是少數被視為與內核等效的用戶服務之一(例如apexdbpfloaderinitueventdvold )。
可信硬件基礎 (THB)離散硬件組件(通常位於 SoC 上),提供對設備核心用例至關重要的功能(例如蜂窩基帶、DSP、GPU 和 ML 處理器)。
引導加載程序鏈一個組件,用於在啟動時配置設備,然後將控制權傳遞給 Android 操作系統。
可信執行環境(TEE)旨在保護其免受惡意操作系統內核影響的組件(例如,TrustZone 和虛擬機管理程序,例如 pKVM,可保護虛擬機免受操作系統內核的影響)。
安全飛地/安全元件 (SE)一種可選硬件組件,旨在保護設備免受設備上所有其他組件和物理攻擊的影響,如安全元件簡介中所定義。

這包括某些 Android 設備中存在的 Titan-M 芯片。

嚴重性

錯誤的嚴重性通常反映了成功利用錯誤後可能發生的潛在危害。使用以下標準來確定嚴重性。

評分成功利用的後果
批判的
  • TEE 或 SE 中的任意代碼執行
  • 繞過旨在防止安全相關軟件或硬件組件發生故障的軟件機制(例如熱保護)
  • 遠程訪問用於遠程服務身份驗證的敏感憑據(例如帳戶密碼或不記名令牌)
  • 在蜂窩基帶上下文中遠程執行任意代碼,無需用戶交互(例如,利用蜂窩無線電服務中的錯誤)
  • 在特權上下文、引導加載程序鏈、THB 或操作系統內核中遠程執行任意代碼
  • 遠程繞過軟件包安裝或等效行為的用戶交互要求
  • 遠程繞過核心開發人員、安全或隱私設置的用戶交互要求
  • 遠程持續拒絕服務(永久,需要重新刷新整個操作系統,或恢復出廠設置)
  • 遠程安全啟動繞過
  • 對 SE 保護的數據進行未經授權的訪問,包括通過 SE 中的弱密鑰啟用的訪問。
高的
  • 完全繞過核心安全功能(例如 SELinux、FBE 或seccomp
  • 深度防禦的一般繞過或利用引導加載程序鏈、TEE 或 SE 中的緩解技術
  • 操作系統保護的一般繞過,可跨應用程序、用戶或配置文件邊界洩露內存或文件內容
  • 針對 SE 的攻擊導致降級為安全性較低的實施
  • 繞過設備保護/恢復出廠設置保護/運營商限制
  • 繞過 TEE 保護的用戶交互要求
  • 允許針對端到端協議進行攻擊的加密漏洞,包括針對傳輸層安全 (TLS) 和藍牙 (BT) 的攻擊。
  • 對用於遠程服務身份驗證的敏感憑據(例如帳戶密碼或不記名令牌)的本地訪問
  • 在特權上下文、引導加載程序鏈、THB 或操作系統內核中執行本地任意代碼
  • 本地安全啟動繞過
  • 鎖屏繞過
  • 本地繞過核心開發人員、安全或隱私設置的用戶交互要求
  • 本地繞過軟件包安裝或等效行為的用戶交互要求
  • 本地持續拒絕服務(永久,需要重新刷新整個操作系統,或恢復出廠設置)
  • 遠程訪問受保護的數據(即僅限於特權上下文的數據)
  • 在非特權上下文中遠程執行任意代碼
  • 在沒有用戶交互的情況下遠程阻止對蜂窩或 Wi-Fi 服務的訪問(例如,使用格式錯誤的數據包使蜂窩無線電服務崩潰)
  • 遠程繞過用戶交互要求(訪問需要用戶啟動或用戶許可的功能或數據)
  • 有針對性地阻止獲得緊急服務
  • 當請求者期望安全傳輸時,通過不安全的網絡協議(例如 HTTP 和未加密的藍牙)傳輸敏感信息。請注意,這不適用於 Wi-Fi 加密(例如 WEP)
  • 對受 TEE 保護的數據進行未經授權的訪問,包括通過 TEE 中的弱密鑰啟用的訪問
緩和
  • 在特權上下文、THB 或操作系統內核中一般繞過深度防禦或利用緩解技術
  • 操作系統保護的一般繞過,可跨應用程序、用戶或配置文件邊界顯示進程狀態或元數據
  • 繞過 Wi-Fi 加密或身份驗證
  • 標準加密原語中的加密漏洞允許洩露明文(不是 TLS 中使用的原語)
  • 對受保護數據的本地訪問(即僅限於特權上下文的數據)
  • 在非特權上下文中執行本地任意代碼
  • 本地繞過用戶交互要求(訪問通常需要用戶啟動或用戶許可的功能或數據)
  • 遠程訪問未受保護的數據(即通常可由任何本地安裝的應用程序訪問的數據)
  • 在受限上下文中遠程執行任意代碼
  • 遠程臨時設備拒絕服務(遠程掛起或重新啟動)
低的
  • 一般繞過用戶級深度防禦或在非特權環境中利用緩解技術
  • 繞過正常保護級別權限
  • 非標準使用中的加密漏洞
  • 一般繞過設備上的個性化功能,例如語音匹配面部匹配
  • 不正確的文檔可能會導致安全漏洞
  • 在受限上下文中執行本地任意代碼
  • 系統定義的文本,其中包含誤導性描述,會產生錯誤的安全期望
安全影響可忽略不計 (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:

Reports

Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.