安全更新和资源

Android 安全团队负责管理在 Android 平台中以及与 Android 设备捆绑在一起的众多核心 Android 应用中发现的安全漏洞。

Android 安全团队会通过内部研究找出安全漏洞，还会对第三方报告的 bug 采取应对措施。外部 bug 的来源包括：通过漏洞表单报告的问题、已发布和预发布的学术研究、上游开源项目维护人员、来自设备制造商合作伙伴的通知，以及博客或社交媒体中发布的已公开披露的问题。

举报安全问题

任何开发者、Android 用户或安全研究人员都可以通过漏洞表单将潜在安全问题告知 Android 安全团队。

外部人员无法查看标记为安全问题的 bug，不过在问题经过评估或得到解决后，这些 bug 最终可能会对外公开。如果您打算提交旨在解决安全问题的补丁或兼容性测试套件 (CTS) 测试，请将其附加到 bug 报告中，然后等待我们的回复，得到我们的回复后再将代码上传到 AOSP。

待分类的错误

在处理安全漏洞时，第一项任务是确定 bug 的严重程度以及受影响的 Android 组件。严重程度决定问题的优先级，受影响的组件决定由谁来修复 bug、谁将会收到通知以及如何将修复程序部署给用户。

上下文类型

下表介绍了硬件和软件安全上下文的定义。 上下文可以按其通常处理的数据的敏感性来定义，也可以按它的运行区域来定义。并非所有安全上下文都适用于所有系统。下表按照权限从小到大的顺序排列。

上下文类型 类型定义
受限上下文 一种受限的执行环境，只有最少的权限。

例如，在沙盒化环境中处理不可信数据的可信应用。
非特权上下文 非特权代码所预期的典型执行环境。

例如，在具有 untrusted_app_all 属性的 SELinux 域中运行的 Android 应用。
特权上下文 特权执行环境，可能有权获得提升的权限，可处理多种用户个人身份信息，并且/或者能够保持系统完整性。

例如，功能会被 SELinux untrusted_app 域禁止或具有 privileged|signature 权限的 Android 应用。
操作系统内核 符合以下条件的功能：
  • 是内核的一部分
  • 在与内核相同的 CPU 环境中运行（例如，设备驱动程序）
  • 能够直接访问内核内存（例如，设备上的硬件组件）
  • 能够将脚本加载到内核组件（例如 eBPF）
  • 属于被视为内核等效功能的一些用户服务之一（例如 apexd、bpfloader、init、ueventd 和 vold）。
可信硬件基 (THB) 独立的硬件组件（通常位于 SoC 上），用于提供对设备的核心用例至关重要的功能（例如移动网络基带、DSP、GPU 和机器学习处理器）。
引导加载程序链 一种组件，能够在设备启动时配置设备，然后将控制权传递给 Android OS。
可信执行环境 (TEE) 一种组件，甚至可以抵御恶意操作系统内核的攻击（例如 TrustZone 和 Hypervisor [如 pKVM]，它们可以保护虚拟机免受操作系统内核的影响）。
安全隔区/安全元件 (SE) 一种可选硬件组件，旨在抵御设备上其他所有组件的攻击以及物理攻击，具体定义请参见安全元件简介。

这包括某些 Android 设备中存在的 Titan-M 芯片。

严重程度

bug 的严重程度通常能够反映 bug 被成功利用后可能造成的潜在危害。可以按照以下条件判断严重程度。

评分 被成功利用的后果
严重
  • 攻击者可以在 TEE 或 SE 中执行任意代码
  • 攻击者可以绕过旨在预防安全相关软件或硬件组件出现故障的软件机制（例如热保护机制）
  • 攻击者可以远程访问用于远程服务身份验证的敏感凭据（例如，账号密码或不记名令牌）
  • 攻击者可以在没有用户互动的情况下，远程在移动网络基带上下文中执行任意代码（例如，利用移动网络无线装置服务中的 bug）
  • 攻击者可以远程在特权上下文、引导加载程序链、THB 或操作系统内核中执行任意代码
  • 攻击者可以远程绕过与软件包安装或等效行为相关的用户互动要求
  • 攻击者可以远程绕过针对核心的开发者、安全或隐私设置而制定的用户互动要求
  • 攻击者可以远程发起持久性拒绝服务攻击（永久性损坏、需要重新刷写整个操作系统或恢复出厂设置）
  • 攻击者可以绕过远程安全启动
  • 攻击者可以在未经授权的情况下访问受 SE 保护的数据，包括通过 SE 中安全系数较低的密钥所实现的访问。
高
  • 攻击者可以完全绕过核心安全功能（例如 SELinux、FBE 或 seccomp）
  • 攻击者可以全面深入地绕过防护功能，或者在引导加载程序链、TEE 或 SE 中利用缓解技术存在的漏洞进行攻击
  • 攻击者可以全面绕过操作系统保护功能，跨越应用、用户或个人资料边界显示内存内容或文件内容
  • 攻击者可以发起针对 SE 的攻击，导致设备降级为安全系数较低的实现
  • 攻击者可以从已遭入侵且可远程访问的裸机固件（例如基带、通信处理器 [CP]）透视到应用处理器 (AP) 内核，或可以绕过旨在将裸机固件与 AP 内核隔离的机制
  • 攻击者可以绕过设备保护服务/恢复出厂设置保护服务、运营商的限制
  • 攻击者可以绕过受 TEE 保护的用户互动要求
  • 攻击者可以利用加密漏洞发起针对端到端协议的攻击，包括发起针对传输层安全协议 (TLS) 和蓝牙 (BT) 的攻击。
  • 攻击者可以从本地访问用于远程服务身份验证的敏感凭据（例如，账号密码或不记名令牌）
  • 攻击者可以从本地在特权上下文、引导加载程序链、THB 或操作系统内核中执行任意代码
  • 攻击者可以绕过本地安全启动
  • 攻击者可以绕过锁定屏幕
  • 攻击者可以从本地绕过针对核心的开发者、安全或隐私设置而制定的用户互动要求
  • 攻击者可以从本地绕过与软件包安装或等效行为相关的用户互动要求
  • 攻击者可以从本地发起持久性拒绝服务攻击（永久性损坏、需要重新刷写整个操作系统或恢复出厂设置）
  • 攻击者可以远程访问受保护的数据（即，仅限特权上下文访问的数据）
  • 攻击者可以在非特权上下文中远程执行任意代码
  • 攻击者可以在没有用户互动的情况下远程阻止对移动网络或 Wi-Fi 服务的访问（例如，用格式不正确的数据包使移动网络无线装置服务崩溃）
  • 攻击者可以远程绕过用户互动要求（攻击者能够访问原本应由用户发起的功能，或能够访问原本应在获得用户许可后方可访问的功能或数据）
  • 有针对性地阻止对应急服务的访问
  • 攻击者可以在请求者期望安全传输时通过不安全的网络协议（例如 HTTP 和未加密的蓝牙）传输敏感信息。请注意，这不适用于 WEP 等 Wi-Fi 加密。
  • 攻击者可以在未经授权的情况下访问受 TEE 保护的数据，包括通过 TEE 中安全系数较低的密钥所实现的访问
中
  • 攻击者可以全面深入地绕过防护功能，或者在特权上下文、THB 或操作系统内核中利用缓解技术存在的漏洞进行攻击
  • 攻击者可以全面绕过操作系统保护功能，跨越应用、用户或个人资料边界显示进程状态或元数据
  • 绕过 WLAN 加密或身份验证
  • 攻击者可以利用标准加密基元（并非 TLS 中使用的基元）中的加密漏洞泄露明文
  • 攻击者可以从本地访问受保护的数据（即，仅限特权上下文访问的数据）
  • 攻击者可以从本地在非特权上下文中执行任意代码
  • 攻击者可以从本地绕过用户互动要求（攻击者能够访问原本应由用户发起的功能，或能够访问原本应在获得用户许可后方可访问的功能或数据）
  • 攻击者可以远程访问不受保护的数据（即，通常可供本地安装的所有应用访问的数据）
  • 攻击者可以在受限上下文中远程执行任意代码
  • 设备遭到远程发起的设备暂时性拒绝服务攻击（远程挂起或重新启动设备）
低
  • 攻击者可以全面深入地绕过用户级防护功能，或在非特权上下文中利用缓解技术存在的漏洞进行攻击
  • 攻击者可以绕过常规保护级别权限
  • 攻击者可以在非标准使用中造成加密漏洞
  • 攻击者可以全面绕过设备端个性化功能，例如 Voice Match 或 Face Match
  • 可能会导致出现安全漏洞的错误文档
  • 攻击者可以从本地在受限上下文中执行任意代码
  • 系统定义的文字包含误导性说明，导致产生虚假的安全预期
可忽略不计的安全影响 (NSI)
  • 漏洞的影响已被一种或多种分级调节方式或特定于版本的架构更改减弱，因此有效严重程度已降至“低”以下，但底层代码问题可能仍然存在
  • 出现某种漏洞，导致需要格式错误的文件系统（如果该文件系统总是在使用之前被采用/加密）。
  • 攻击者可用从本地发起暂时性拒绝服务攻击，例如可以通过重新启动设备或卸载触发性应用来解决相应问题。

分级调节方式

尽管通常可以轻松确定安全漏洞的严重程度，但分级可能会因具体情况而异。

原因 效果
需要作为特权上下文运行才能执行攻击（不适用于 TEE、SE 以及 Hypervisor [如 pKVM]） 严重程度降低 1 级
漏洞特有的详细信息限制了相应问题的影响大小 严重程度降低 1 级
绕过需要直接从设备所有者获得生物识别信息的生物识别验证 严重程度降低 1 级
编译器或平台配置缓解了源代码中的漏洞 如果底层漏洞的严重程度为“中”或更高，则实际严重程度为“中”
需要实际接触设备内部，如果设备已关机或开机后尚未解锁，则仍然可以访问 严重程度降低 1 级
在设备处于开机状态且之前已解锁时需要实际接触设备内部 严重程度降低 2 级
需要解锁引导加载程序链才能进行本地攻击 不高于“低”
需要当前在设备上启用了开发者模式或任何持久性开发者模式设置（且本身不是开发者模式中的 bug）才能进行本地攻击 不高于“低”
如果任何 SELinux 域都无法在 Google 提供的 SEPolicy 下执行操作 可忽略不计的安全影响

本地攻击、邻近攻击以及远程攻击对比

远程攻击途径指攻击者可以在不安装应用或不实际接触设备的情况下利用的 bug。这包括因浏览网页、阅读电子邮件、接收短信或连接到恶意网络而触发的 bug。

邻近攻击途径被视为远程攻击途径。这包括只能被实际接近目标设备的攻击者利用的 bug，例如需要发送格式错误的 Wi-Fi 数据包或蓝牙数据包的 bug。我们将超宽带 (UWB) 和基于 NFC 的攻击视为邻近攻击，因此它们属于远程攻击。

本地攻击需要攻击者事先接触受害者。在假设的仅软件的示例中，这可以通过受害者安装的恶意应用或他们同意运行的免安装应用来实现。

已成功配对的设备（例如蓝牙配套设备）会被视为本地设备。我们会区分已配对的设备和正在参与配对流程的设备。

  • 导致用户识别要配对的其他设备的能力（即身份验证能力）下降的 bug 被视为邻近 bug，因此属于远程 bug。
  • 在配对流程中但在用户同意（即授权）之前发生的 bug 被视为邻近 bug，因此属于远程 bug。
  • 在用户同意之后发生的 bug 会被视为本地 bug，即使配对最终失败也是如此。

物理攻击途径被视为本地攻击途径。这包括只能被实际接触到设备的攻击者利用的 bug，例如锁定屏幕中的 bug，或需要插入 USB 线的 bug。由于在插入 USB 后设备经常会处于解锁状态，因此无论设备是否需要解锁，需要 USB 连接的攻击的严重程度都是相同的。

网络安全

Android 假设所有网络都是恶意网络且可能会注入攻击或监视流量。虽然链路层安全保护机制（例如 Wi-Fi 加密）可以保护设备与其连接到的接入点之间的通信，但不会保护设备和与其通信的服务器之间的链中的其余链路。

相比之下，HTTPS 通常会对整个通信进行端到端保护，方法是在源位置对数据进行加密，只有在到达最终目标位置后才对数据进行解密和验证。正因如此，损害链路层网络安全的漏洞的严重程度分级低于 HTTPS/TLS 中的漏洞：对于互联网上的大部分通信而言，仅靠 Wi-Fi 加密是不够的。

生物识别身份验证

生物识别验证是一个具有挑战性的领域，即使是最好的系统，也可能会被近乎匹配的生物特征欺骗（请参阅 Android 开发者博客：Android 11 中的锁定屏幕和身份验证改进）。这些严重程度分级区分了两类攻击，旨在反映给最终用户带来的实际风险。

第一类攻击使攻击者能够以一种可泛化的方式绕过生物识别验证，而无需所有者提供高质量的生物识别数据。例如，如果攻击者可以在指纹传感器上放一块口香糖，它根据传感器上的残留物授予对设备的访问权限，这是攻击者可能会在任何易受攻击的设备上执行的一种简单攻击。不要求对设备的所有者有任何了解。鉴于这种攻击可泛化且可能会影响更多用户，因此会得到完整的严重程度分级（例如，“攻击者可以绕过锁定屏幕”的严重程度为“高”）。

另一类攻击通常涉及基于设备所有者的演示攻击手段（仿冒）。有时，这种生物识别信息相对容易获取（例如，如果某人在社交媒体上的个人资料照片足以骗过生物识别验证，则“攻击者可以绕过生物识别验证”会得到完整的严重程度分级）。但是，如果攻击者需要直接从设备所有者获取生物识别数据（例如，对他们的面孔进行红外扫描），这是一种足够有力的障碍，可以限制受攻击影响的人数，因此应用调节方式后严重程度降低 1 级。

SYSTEM_ALERT_WINDOW 和点按劫持

如需了解我们关于 SYSTEM_ALERT_WINDOW 和点按劫持的政策，请参阅 BugHunter University 的对安全没有影响的 bug 页面上的“非安全关键型屏幕上的点按劫持/叠加层 SYSTEM_ALERT_WINDOW 漏洞”部分。

Android Automotive OS 中的多用户安全模型

Android Automotive OS 采用不同于其他设备规格的多用户安全模型。每个 Android 用户意指一个与他人不同的自然人。例如，可以将一个临时访客用户分配给一个向车主借用车辆的朋友。为了适应此类使用情形，默认情况下，用户可以访问使用车辆所需的必要组件，例如 Wi-Fi 和移动网络设置。

受影响的组件

开发团队负责根据 bug 所在的组件来修复 bug。具体组件可能是 Android 平台的核心组件、原始设备制造商 (OEM) 提供的内核驱动程序，或 Pixel 设备上某个预加载的应用。

AOSP 代码中的错误由 Android 工程团队负责修复。严重程度为“低”的 bug、特定组件内的 bug 或者已经是众所周知的 bug 可以直接在已公开发布的 AOSP main 分支中进行修复；除此之外的其他 bug 都会先在我们的内部代码库中进行修复。

组件也是会影响用户如何获取更新的一种因素。如果是框架或内核存在的 bug，用户需要使用无线下载 (OTA) 的固件更新，每个 OEM 都需要推送此类更新。如果是 Google Play 中发布的应用或库（例如，Gmail、Google Play 服务或 WebView）存在的 bug，则可以通过 Google Play 向 Android 用户发送更新。

通知合作伙伴

在 Android 安全公告中公布已修复 AOSP 中的某个安全漏洞后，我们会将问题详细信息通知给 Android 合作伙伴，并提供相应的补丁。具体有哪些支持向后移植的版本，会随着每个新 Android 版本的发布而发生变化。如需查看支持的设备的列表，请与设备制造商联系。

向 AOSP 发布代码

如果安全 bug 发生在 AOSP 组件内，我们会先向用户发布 OTA 更新，然后再将修复推送到 AOSP。如果问题的严重程度为“低”，我们可能会先直接将修复提交到 AOSP main 分支，然后再通过 OTA 更新将其提供给设备。

接收 Android 更新

对 Android 系统的更新一般会通过 OTA 更新包提供给设备。这些更新可能来自生产相应设备的 OEM，也可能来自向相应设备提供服务的运营商。Google Pixel 设备更新由 Google Pixel 团队在相应更新通过运营商技术验收 (TA) 测试程序之后予以提供。Google 还会发布可以旁加载到设备的 Pixel 出厂映像。

更新 Google 服务

除了针对安全 bug 提供补丁之外，Android 安全团队还会审核安全 bug，确定是否有其他方式来保护用户。例如，Google Play 会扫描所有应用并移除任何试图利用安全 bug 的应用。对于通过 Google Play 之外的途径安装的应用，带有 Google Play 服务的设备可能还会使用验证应用功能来警告用户注意可能有害的应用。

其他资源

面向 Android 应用开发者的信息：https://developer.android.com

您可以从各个 Android 开放源代码和开发者网站上找到安全信息。最好从以下网址入手：

报告

Android 安全团队有时会发布报告或白皮书。如需了解详情，请参阅安全报告。