安全性更新和資源

Android 安全性團隊的職責是管理 Android 平台中找到的安全漏洞,以及 Android 裝置隨附的許多核心 Android 應用程式。

Android 安全性團隊會透過內部研究找出安全漏洞,也會對第三方回報的錯誤做出回應。外部錯誤的來源很多,包括透過安全漏洞表單回報的問題、已發布和預先發布的學術研究、上游開放原始碼專案維護人員、裝置製造商合作夥伴的通知,以及網誌或社群媒體上公開揭露的問題。

回報安全性問題

不論是開發人員、Android 使用者或安全性研究人員,都可以透過安全漏洞表單將潛在的安全性問題告知 Android 安全性團隊。

標示為安全性問題的錯誤不會對外公開,但可能會在問題評估或解決後顯示。如果您預計提交修補程式或 Compatibility Test Suite (CTS) 測試來解決安全性問題,請在錯誤報告中提供相應附件。等到接獲回覆後,再將程式碼上傳到 Android 開放原始碼計畫中。

將錯誤分類

處理安全漏洞時,首先要做的是判別錯誤嚴重程度,並瞭解哪個 Android 元件受到影響。嚴重程度會決定問題的優先處理順序,而元件則用於判定應由誰修正錯誤、要通知哪些對象,以及如何為使用者部署修正內容。

環境類型

下表列出硬體和軟體安全環境的定義。環境可以按其一般所處理資料的機密程度來定義,也可按執行範圍定義,並非所有安全環境都適用於所有系統。下表將依特殊權限多寡,由低到高列出各種環境。

環境類型 類型定義
受限的環境 僅提供最少權限的受限執行環境。

例如,受信任的應用程式在沙箱環境中處理不受信任的資料。
沒有特殊權限的環境 適合沒有特殊權限的程式碼執行的典型環境。

舉例來說,Android 應用程式在具有 untrusted_app_all 屬性的 SELinux 網域中執行,就屬於這種情況。
具有特殊權限的環境 具有特殊權限的執行環境,可能可以使用進階權限、處理多個使用者 PII,及/或維護系統完整性。

舉例來說,Android 應用程式含有遭 SELinux untrusted_app 網域禁止的功能,或是具備 privileged|signature 權限,就屬於這種情況。
OS 核心 功能:
  • 是核心的一環
  • 會在與核心相同的 CPU 環境 (例如裝置驅動程式) 中執行
  • 可直接存取核心記憶體 (例如裝置上的硬體元件)
  • 可將指令碼載入核心元件 (例如 eBPF)
  • 是少數被視為與核心等效的使用者服務之一 (例如 apexdbpfloaderinitueventdvold)。
受信任的硬體基礎 (THB) 獨立的硬體元件,通常位於 SoC,可依據裝置核心用途提供重要功能 (例如行動網路基頻、DSP、GPU 和機器學習處理器)。
系統啟動載入程式鏈結 裝置啟動時,此元件可設定裝置,然後將控制權交給 Android 作業系統。
受信任的執行環境 (TEE) 此元件經過設計,即使遭受惡意 OS 核心攻擊也能安全無虞。舉例來說,TrustZone 和管理程序 (例如 pKVM) 可以防止虛擬機器受到 OS 核心影響。
安全隔離區/安全元件 (SE) 選用的硬體元件,旨在防止物理攻擊,避免受到裝置上所有其他組件的影響,如「Introduction to Secure Elements」(安全元件簡介) 所述。

包括部分 Android 裝置內建的 Titan M 晶片。

嚴重程度

一般來說,錯誤的嚴重程度能反映有心人士成功利用錯誤後,可能造成怎樣的潛在危害。判斷嚴重程度時,請以下列條件為基準。

Rating 漏洞遭到利用的後果
最高
  • 在 TEE 或 SE 中執行任意程式碼
  • 規避為了防範安全相關軟體/硬體元件故障而設計的軟體機制 (例如熱防護)
  • 從遠處存取用於遠端服務驗證的機密憑證 (例如帳戶密碼或不記名權杖)
  • 在未與使用者互動的情況下,於行動網路基頻環境中遠端執行任意程式碼 (例如利用手機無線電服務中的錯誤)
  • 在具有特殊權限的環境、系統啟動載入程式鏈結、THB 或 OS 核心中,從遠端執行任意程式碼
  • 從遠端規避與套件安裝或同等行為相關的使用者互動要求
  • 從遠端規避針對核心開發人員、安全性或隱私權設定的使用者互動要求
  • 從遠端持續阻斷服務 (永久性損壞、需要重新刷新整個作業系統或恢復原廠設定)
  • 規避遠端安全啟動機制
  • 在未獲授權的情況下存取由 SE 保護的資料,包括 SE 內低強度金鑰導致的存取行為。
  • 完全規避核心安全防護功能 (例如 SELinux、FBE 或 seccomp)
  • 在系統啟動載入程式鏈結、TEE 或 SE 中,規避一般的縱深防禦措施或防範攻擊技術
  • 規避一般的作業系統防護機制,這通常會造成應用程式、使用者或設定檔邊界的記憶體或檔案內容洩漏
  • 攻擊 SE,導致降級至安全性較低的實作方式
  • 從可遠端存取的受損裸機韌體 (例如基頻、通訊處理器 (CP)) 轉向應用程式處理器 (AP) 核心,或規避用來隔離裸機韌體與 AP 核心的機制
  • 規避裝置保護機制、恢復原廠設定保護機制或電信業者限制
  • 規避受到 TEE 保護的使用者互動要求
  • 導致針對端對端通訊協定攻擊的加密編譯漏洞,包括對傳輸層安全標準 (TLS) 和藍牙 (BT) 發動攻擊。
  • 在本機存取用於遠端服務驗證的機密憑證 (例如帳戶密碼或不記名權杖)
  • 在具有特殊權限的環境、系統啟動載入程式鏈結、THB 或 OS 核心中,從本機執行任意程式碼
  • 規避本機安全啟動機制
  • 規避螢幕鎖定機制
  • 從本機規避針對核心開發人員、安全性或隱私權設定的使用者互動要求
  • 從本機規避與套件安裝或同等行為相關的使用者互動要求
  • 從本機持續阻斷服務 (永久性損壞、需要重新刷新整個作業系統或恢復原廠設定)
  • 從遠端存取受保護的資料 (即僅可在具有特殊權限的環境存取的資料)
  • 在沒有特殊權限的環境中,從遠端執行任意程式碼
  • 在未與使用者互動的情況下,從遠端禁止存取行動網路或 Wi-Fi 服務 (例如,使用格式錯誤的封包造成手機無線電服務當機)
  • 從遠端規避使用者互動要求 (使用需要使用者啟動或特定使用者權限的功能或資料)
  • 有針對性地禁止使用緊急救援服務
  • 在要求者預期進行安全傳輸時,透過不安全的網路通訊協定 (例如 HTTP 和未加密的藍牙) 傳輸機密資訊。請注意,這不適用於 WEP 這類 Wi-Fi 加密機制。
  • 在未獲授權的情況下存取受 TEE 保護的資料,包括 TEE 內低強度金鑰導致的存取行為
中等
  • 在具備特殊權限的環境、THB 或 OS 核心中,規避一般的縱深防禦或防範攻擊技術
  • 規避一般的作業系統防護機制,這通常會造成應用程式、使用者或設定檔邊界的程序狀態或中繼資料洩漏
  • 規避 Wi-Fi 加密或驗證機制
  • 導致標準密碼基元中的加密編譯漏洞,造成明文 (非 TLS 中使用的基元) 外洩
  • 從本機存取受保護的資料 (即僅可在具有特殊權限的環境存取的資料)
  • 在沒有特殊權限的環境中,從本機執行任意程式碼
  • 從本機規避使用者互動要求 (使用通常需要使用者啟動或特定使用者權限的功能或資料)
  • 從遠端存取未受保護的資料 (也就是任何安裝在本機的應用程式通常都能存取的資料)
  • 在受限的環境中,從遠端執行任意程式碼
  • 從遠端暫時阻斷裝置服務 (從遠端停止或重新啟動裝置)
  • 在沒有特殊權限的環境中,規避一般使用者層級縱深防禦措施或防範攻擊技術
  • 規避正規的防護等級權限
  • 在非標準使用情況下導致加密編譯漏洞
  • 規避一般的裝置端個人化功能 (例如 Voice Match Face Match)
  • 提供錯誤的說明文件,可能會導致出現安全漏洞
  • 在受限的環境中,從本機執行任意程式碼
  • 系統定義的文字包含誤導性說明,導致產生錯誤的安全期望
可忽略的安全性影響 (NSI)
  • 一或多個分級修正因素 (或特定版本的架構變更) 導致安全漏洞的影響程度降低;儘管基本的程式碼問題可能仍存在,但實際嚴重程度已降至「低」以下
  • 出現某種安全漏洞,導致需要格式錯誤的檔案系統 (如果該檔案系統一律在使用前合併/加密的話)。
  • 本機暫時阻斷服務,例如重新啟動裝置或解除安裝觸發的應用程式,即可解決的情況。

費率調節係數

安全漏洞的嚴重程度通常很容易辨識,但分級可能會因情況而有所改變。

原因 效果
需要在具有特殊權限的環境下執行,才能發動攻擊 (不適用於 TEE、SE 和 pKVM 這類管理程序) 嚴重程度降低 1 級
因閱讀特定安全漏洞詳情,有效控制了問題的影響程度 嚴重程度降低 1 級
規避生物特徵辨識驗證。這類驗證方式必須直接從裝置擁有者身上取得生物特徵辨識資訊 嚴重程度降低 1 級
編譯器或平台設定緩解了原始碼中的安全漏洞 如果基本安全漏洞問題的嚴重程度為「中等」以上,則此處嚴重程度降為「中等」
需實際存取裝置內部,如果裝置已關機 (或開機後尚未解鎖),則仍然可以存取 嚴重程度降低 1 級
在裝置開機且先前曾解鎖的情況下,需要實際存取裝置內部 嚴重程度降低 2 級
需要解鎖系統啟動載入程式鏈結,才能發動本機攻擊 不高於「低」
需要在裝置上啟用「開發人員模式」或任何常駐的開發人員模式設定 (且本身不是「開發人員模式」中的錯誤),才能發動本機攻擊。 不高於「低」
沒有任何 SELinux 網域可在 Google 提供的 SEPolicy 下執行操作 可忽略的安全性影響

本機、鄰近與遠端

所謂遠端攻擊向量,是指攻擊者在利用錯誤時,可以不安裝應用程式或不實際存取裝置。這包括因瀏覽網頁、讀取電子郵件、接收簡訊或連上惡意網路而觸發的種種錯誤。

鄰近攻擊向量視為遠端攻擊向量。這包括只能由實際位於目標裝置附近的攻擊者利用的錯誤,例如需要傳送格式有誤的 Wi-Fi/藍牙封包的錯誤。我們將超寬頻 (UWB) 和 NFC 式的攻擊視為鄰近攻擊,因此也可說是遠端攻擊。

攻擊者必須先取得受害者的存取權,才能發動本機攻擊。在假設的僅限軟體範例中,這可能是透過受害者安裝的惡意應用程式,或是他們同意執行的免安裝應用程式

已成功配對的裝置 (例如藍牙隨附裝置) 會視為本機。我們會區分已配對的裝置,以及參與配對流程的裝置。

  • 會降低使用者識別配對裝置的能力 (即驗證) 的錯誤,會被視為近端錯誤,因此屬於遠端錯誤。
  • 在配對流程中發生的錯誤,如果發生在使用者同意 (即授權) 之前,就會被視為近端錯誤,因此是屬於遠端錯誤。
  • 在取得使用者同意聲明後發生的錯誤,即使最終配對失敗,也視為本機錯誤。

實體攻擊向量視為本機攻擊向量。這包括僅可由實際操作裝置的攻擊者發動的錯誤,例如螢幕鎖定中的錯誤,或是需要插入 USB 傳輸線的錯誤。由於裝置在插入 USB 時經常會解鎖,因此無論裝置是否需要解鎖,只要攻擊牽涉到 USB 連線,嚴重程度也就相同。

網路安全

Android 會假設所有網路都含有惡意內容,這些內容可能發動注入式攻擊或監視流量。雖然連結層的安全防護機制 (例如 Wi-Fi 加密) 可以保護裝置和所連存取點間的通訊,但這樣做並不會保護裝置與目標通訊伺服器間鏈結的其餘連結。

相比之下,HTTPS 通常會以端對端的方式保護整個通訊過程,做法是在來源位置加密資料,僅在資料抵達最終目的地時才解密及驗證資料。因此,如果漏洞會危及連結層的網路安全,嚴重程度分級就會低於 HTTPS/TLS 中的安全漏洞,因為單靠 Wi-Fi 加密並不足以支援網際網路上的多半通訊作業。

生物特徵辨識驗證

生物特徵辨識驗證這個領域很有挑戰性,即使是最頂尖的系統都可能被「近似比對」的手法欺騙 (請參閱「Android 開發人員網誌:Android 11 的螢幕鎖定和驗證強化項目」)。此領域的嚴重程度分級區分了兩種攻擊,旨在反映使用者實際面臨的風險。

第一類攻擊能以一般化的方式規避生物特徵辨識驗證,而不要求擁有者提供高品質的生物特徵辨識資料。舉例來說,假設攻擊者只要在指紋感應器上放一塊口香糖沾取殘餘指紋,就可以獲得存取裝置的權限,那麼他在任何易受影響的裝置上都可以輕鬆發動攻擊,即使完全不瞭解裝置擁有者也無妨。由於這類攻擊可一般化,且可能影響大量使用者,因此嚴重程度評定為滿級分 (舉例來說,如果攻擊者能規避螢幕鎖定,嚴重程度則屬於「高」)。

另一類攻擊通常涉及一種手段,也就是冒用裝置擁有者的身分 (假冒)。有時,這類生物特徵辨識資訊相對容易取得 (舉例來說,如果光靠某人在社群媒體上的個人資料相片,就足以騙過生物特徵辨識驗證機制,那麼對於規避生物特徵辨識的行為,嚴重程度會評定為滿級分)。不過,假如攻擊者需要直接向裝置擁有者取得生物特徵辨識資料 (例如臉部的紅外線掃描資訊),這樣就會造成足夠程度的阻礙,從而限制了受攻擊影響的人數,因此修正後的嚴重程度會降低 1 級。

SYSTEM_ALERT_WINDOW 和 Tapjacking

如要瞭解有關 SYSTEM_ALERT_WINDOW 和 Tapjacking 的政策,請前往 BugHunter University 的「 沒有安全性影響的錯誤」頁面,閱讀「Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen」(非攸關安全畫面上的 Tapjacking/overlay SYSTEM_ALERT_WINDOW 安全漏洞) 一節。

Android Automotive OS 中的多使用者安全性

Android Automotive OS 採用不同於其他板型規格的多使用者安全性模型。每個 Android 使用者身分,都是由獨立的自然人使用。舉例來說,車主可以為借車的朋友指派臨時訪客使用者身分。為了因應這類用途,使用者在預設情況下即可存取使用車輛所需的各種必要元件,例如 Wi-Fi 和行動網路設定。

受影響的元件

要由哪個開發團隊負責修正錯誤,需視錯誤所在的元件而定。這可能是 Android 平台的核心元件、原始設備製造商 (OEM) 提供的核心驅動程式,或是 Pixel 裝置上預先載入的其中一款應用程式。

如果 Android 開放原始碼計畫 (AOSP) 程式碼中出現錯誤,Android 工程團隊會負責修正。假設出現嚴重程度「低」的錯誤、特定元件內的錯誤,或眾所周知的錯誤,可能會直接在公開發布的 AOSP 主要分支版本中修正;其餘錯誤則先在內部存放區中修正。

使用者如何接收更新,也會受到元件影響。如果是架構或核心中的錯誤,就必須用到無線更新 (OTA),所有原始設備製造商 (OEM) 都需推送這個韌體更新。如果錯誤來自 Google Play 中發布的應用程式或程式庫 (例如 Gmail、Google Play 服務或 WebView),則可能會由 Google Play 傳送更新給 Android 使用者。

通知合作夥伴

修正 Android 開放原始碼計畫的安全漏洞後,我們會利用 Android 安全性公告將問題詳情告知 Android 合作夥伴,並提供修補程式。具體有哪些向後移植的支援版本,會隨著每次 Android 新版本發布而變化。如需支援的裝置清單,請與您的裝置製造商聯絡。

將程式碼發布到 Android 開放原始碼計畫

如果 Android 開放原始碼計畫元件出現安全性錯誤,我們會先向使用者發布 OTA,然後再將相關修正程式推送至 Android 開放原始碼計畫。如果問題的嚴重程度低,修正程式可能會直接提交至 Android 開放原始碼計畫的主要分支版本,再透過 OTA 向裝置發布。

接收 Android 更新

Android 系統如有更新,通常會透過 OTA 更新套件的形式提供給裝置。這些更新可能來自生產裝置的原始設備製造商 (OEM) 或為裝置提供服務的電信業者。如過是 Google Pixel 裝置的更新,會由 Google Pixel 團隊在完成電信業者的技術驗收 (TA) 測試程序後提供。Google 也會發布 Pixel 原廠映像檔,供使用者側載至裝置。

更新 Google 服務

除了提供安全性錯誤的修補程式外,Android 安全性團隊也會審查安全性錯誤,判斷是否有其他保護使用者的方式。舉例來說,Google Play 會掃描所有應用程式,並移除任何嘗試利用安全性錯誤的應用程式。對於從 Google Play 外部安裝的應用程式,搭載 Google Play 服務的裝置也可能會使用「 驗證應用程式」功能,警告使用者注意可能有害的應用程式。

其他資源

Android 應用程式開發人員須知: https://developer.android.com

您可以在 Android 開放原始碼和開發人員網站上找到安全性資訊。建議參考以下網址:

報表

Android 安全性團隊有時會發布報告或白皮書。詳情請參閱「安全性報告」。