Pixel 9 零点击漏洞利用链第三部分：我们该何去何从？

在我们之前的两篇博客文章中，我们提供了技术建议，以增加攻击者开发0点击漏洞利用链所需的成本。然而，我们在发现、报告和利用这些漏洞的过程中，也凸显了Android生态系统中一些更广泛的问题。本文将描述我们遇到的问题以及改进建议。

音频攻击面

杜比UDC是大多数Android设备0点击攻击面的一部分，这源于Google Messages应用中的音频转录功能。在用户与消息交互之前，传入的音频消息就会被转录。在Pixel 9上，另一个进程 com.google.android.tts 也会解码传入的音频。其目的尚不完全清楚，但似乎与使传入消息可搜索有关。

这两个进程都使用设备上所有可用的解码器来解码音频，包括UDC。UDC由大多数设备的OEM集成，尽管大部分传入消息只使用少数几种音频格式。特别是，传入消息包含杜比UDC支持的格式的音频的可能性非常低，因为Android设备不提供这些格式的编码器，而且它们主要用于商业媒体，如电影和电视节目。将UDC和其他不常用的解码器从Android的0点击攻击面中移除，可以保护用户免受这些编解码器中漏洞的最严重后果。

手机上AI功能的激增有可能极大地增加其0点击攻击面。虽然这种权衡有时可能对用户有益，但移动厂商必须意识到这对安全性的影响。软件变更无意中增加了攻击者可以远程利用的代码量的情况并不少见。为了保护用户，需要持续审查新功能如何影响0点击和1点击攻击面，并做出审慎的决策。

漏洞发现时间线

这项研究的一个令人惊讶的方面是我们发现漏洞利用链中使用的两个漏洞的速度之快。Project Zero将杜比UDC作为为期一周的团队黑客马拉松的一部分进行了审查，Ivan用了不到两天时间就发现了CVE-2025-54957。同样，Seth在审查BigWave驱动不到一天后就发现了CVE-2025-36934。

当然，很容易忘记发现这些攻击面所付出的努力——杜比黑客马拉松需要大约三周的准备时间来研究编解码器的入口点并设置调试工具，同样，审查BigWave驱动涉及一个驱动程序分析工具，该工具大约花了4周时间开发。在审查杜比UDC之前，我们还审查了其他音频编解码器，结果好坏参半。

尽管如此，与这个漏洞利用链的影响相比，发现必要漏洞所需的时间投入是很少的，尤其是对于权限提升阶段。此外，我们花费大量时间发现的UDC漏洞是一次性成本，我们预计这将有助于未来的研究。对于一个资源充足的攻击者来说，在Android上找到0点击漏洞利用链所需的时间几乎肯定可以用人周来衡量。

Android通过漏洞奖励计划以及使用OSS-Fuzz等工具进行模糊测试，在媒体编解码器的安全性方面投入了大量精力。虽然模糊测试不太可能发现这个特定的UDC漏洞，但据我们所知，Pixel的模糊测试工作并未覆盖UDC。厂商对其攻击面理解的空白是0点击漏洞的常见来源。虽然漏洞也出现在安全防护严密的组件中，但攻击者更容易专注于被忽视的领域。Android和OEM可以从对其0点击攻击面的严格分析以及全面的模糊测试和审查工作中受益。

另一方面，驱动程序在Android上继续成为一个“软目标”。虽然Android及其上游驱动程序供应商（如三星、高通、ARM和Imagination）已经做出了一些努力来提高驱动程序安全性，但这些努力赶不上攻击者发现和利用这些漏洞的能力。自2023年以来，Google威胁情报小组（GTIG）已检测并报告了16个在野被攻击者利用的Android驱动程序漏洞。驱动程序安全仍然是影响Android用户的紧迫问题，可能需要多种方法来改进。用Rust等托管语言重写最易受攻击的驱动程序、对新驱动程序进行持续的安全审查、减少非特权上下文对驱动程序的访问以及使驱动程序代码在Android设备上更容易更新，这些可能都是必要的，以对抗攻击者在该领域的广泛能力。

漏洞利用的难易程度

我们估计，在漏洞利用链中利用杜比UDC漏洞花费了八人周，而利用BigWave驱动程序漏洞进行基本概念验证则花费了3周。考虑到这类漏洞利用链给攻击者带来的巨大能力，这并不算很长时间。虽然许多Android安全功能增加了我们利用这些问题的挑战，但也有两种缓解措施未能提供其文档中描述的保护，这让我们感到惊讶。

Pixel 9上的杜比UDC解码器进程缺少seccomp策略，尽管该策略在AOSP和我们测试的其他几款Android 16设备中已实现。如果AOSP中的策略在Pixel 9上得到强制执行，它很可能至少会增加一个月的时间来开发这个漏洞利用。为了使安全功能有效，定期验证它们非常重要，最好是每个版本都验证，否则回归问题可能会被忽视。

我们还发现，由于一个自2016年以来就已知的问题（详见这篇博客文章），kASLR在Pixel设备上无效。Android和Linux都决定将恢复其有效性的开发工作优先级降低。这个决定使得利用BigWave漏洞变得更加容易，我们估计，如果kASLR有效，利用这个漏洞大约需要多花六周时间，不过考虑到额外所需的时间，我们可能就不会去尝试了。

同样值得注意的是，到目前为止，我们尚未能在Mac或iPhone上成功利用杜比UDC漏洞，因为它使用了-fbounds-safety编译器标志进行编译，该标志添加了内存边界检查，防止了越界写入。杜比应考虑在所有平台上提供此类基于编译器的保护。苹果最近也在新设备上实现了MIE，这是一种类似于内存标记（MTE）的基于硬件的内存保护技术。虽然由于UDC使用自定义分配器，MIE无法阻止在缺少-fbounds-safety的情况下利用杜比UDC漏洞，但它会概率性地阻碍类似于BigWave驱动程序漏洞的iOS内核漏洞被利用。

Pixel 8及更高版本已搭载MTE，但不幸的是，除了选择加入高级保护模式的用户外，该功能并未启用，这对Pixel的其他用户造成了损害。苹果尽管有财务和性能成本，但仍包含内存保护功能，这在保护其用户免受UDC漏洞利用以及可能的内核权限提升方面显然取得了成效。Android用户也有可能得到类似的保护。

这个漏洞利用链的另一个显著特点是它包含的漏洞数量之少。从0点击上下文获取内核权限仅需要两个软件缺陷。在某些平台上，由于有效的沙箱和其他权限限制功能，通常需要更长的漏洞利用链。为了绕过这些，攻击者需要找到多个漏洞，通过多个上下文来提升权限。这表明Android上存在潜在的沙箱化机会，特别是在减少经常成为攻击目标的媒体解码进程的权限方面。

补丁时间线

这个漏洞利用链中的两个漏洞都曾在一段时间内公开且未在Pixel上修复。UDC漏洞于2025年6月26日报告给杜比，首批二进制修复于2025年9月18日推送到ChromeOS。Pixel向我们透露，他们直到2025年10月8日才收到杜比提供的二进制补丁。根据Project Zero的披露政策，在30天的补丁采用期后，我们于2025年10月15日公开披露了该漏洞。三星是第一个修补该漏洞的移动厂商，时间是2025年11月12日。Pixel直到2026年1月5日才发布该漏洞的补丁。

一个在0点击上下文中可利用的漏洞需要139天才能在任意Android设备上获得补丁，而Pixel则多花了54天，这令人担忧。该漏洞在Pixel修补之前已公开82天。

修复缓慢的一个原因可能是杜比的公告。我们在提交漏洞时告知杜比此问题高度可利用，并在工作进展过程中提供了状态更新，包括我们漏洞利用的技术细节。尽管如此，公告中对漏洞影响的描述如下：

我们了解到一份关于Google Pixel设备的报告表明，如果此漏洞与其他已知的Pixel漏洞结合使用，可能会增加漏洞风险。其他Android移动设备可能存在类似的漏洞风险。

这不是对该漏洞所构成风险的准确评估。如本博客文章第一部分所示，该漏洞本身就可被利用，无需额外的漏洞。杜比可能指的是在Android上从mediacodec上下文提升权限需要额外的漏洞，但几乎所有现代漏洞都需要这一点，并且我们告知他们，有强有力的证据表明漏洞利用供应商在大多数Android设备上拥有内核权限提升漏洞。我们遇到的其他厂商都没有将允许在沙箱化上下文中执行代码的漏洞描述为需要“与其他已知漏洞结合使用”。

杜比的公告还说：

对于其他设备类别，我们认为恶意利用此漏洞的风险较低，最常见的结果是媒体播放器崩溃或重启。

我们认为这低估了该漏洞对其他平台的风险。很难确定“攻击者恶意利用此漏洞的风险”，即使是像GTIG这样资源充足的威胁分析团队，也很难对特定漏洞做出任何准确的判断。此外，“最常见的结果是媒体播放器崩溃或重启”这一点，即使对于最严重的内存损坏漏洞也是如此。这就是为什么大多数安全团队根据攻击者利用漏洞可能获得的最大访问权限来对漏洞进行分类。除了在苹果设备上（UDC使用-fbounds-safety编译），此漏洞允许在UDC运行的上下文中执行代码。此漏洞对用户的影响也取决于平台，例如，在Android上风险更高，因为不受信任的音频文件无需用户交互即可被处理，而在智能电视上，它只播放来自少数受信任流媒体源的音频，但这并不改变攻击者通常可以通过利用此漏洞实现代码执行的事实。理想情况下，杜比本应向其集成商提供这些信息，并允许他们根据UDC的使用方式和沙箱化程度来做出风险决策。

目前尚不清楚杜比向Android和Pixel提供了什么信息，但Android在此处发布了其优先级矩阵。由于mediacodec被视为受限上下文，当我们报告时，UDC漏洞属于“受限上下文中的远程任意代码执行”类别，被评为中等。相反，三星将此漏洞评为严重。Android向我们透露，他们最近更新了优先级矩阵，未来此类漏洞将被归类为严重。

我们于2025年6月20日向Pixel报告了BigWave漏洞，它也被评为中等。根据上述矩阵，“特权上下文、引导加载程序链、THB或操作系统内核中的本地任意代码执行”使此漏洞的基础严重性为高，但应用了严重性修饰符“需要以特权上下文运行才能执行攻击”。虽然修饰符文本提到了“特权上下文”，但根据我们的经验，该修饰符经常应用于无法直接从非特权上下文访问的漏洞，包括那些可以从mediacodec等受限上下文访问的漏洞。该漏洞的严重性于2025年9月18日更改为高，并于2026年1月6日向设备推送了修复。根据我们的披露政策，我们在90天后，即2025年9月19日公开分享了该漏洞。

虽然不同的软件供应商和项目在漏洞优先级排序方面有不同的理念，但将这两个漏洞的优先级降低，使用户容易受到0点击漏洞利用链的攻击。一些厂商将0点击入口点中的漏洞设为高优先级，而另一些厂商则选择优先处理隔离这些入口点的沙箱中的漏洞。每种方法都有利弊，但厂商至少需要优先处理漏洞链中的一个漏洞，以便为用户提供针对0点击漏洞利用的基本保护。

这种责任分散在漏洞管理中并不少见。一系列可以组合起来对用户造成严重危害的漏洞往往被单独降低优先级，像杜比这样的编解码器供应商通常认为减轻内存损坏漏洞的影响主要是平台的责任，而像Android这样的平台则过于依赖其供应链无漏洞。具有最佳安全态势的软件开发者倾向于采取这样的立场：所有外部软件都应被视为已遭入侵，并投资于防范这种可能性。这种以及其他纵深防御方法使得攻击者难以构建漏洞利用链，并最有可能保护用户。

补丁传播

尽管杜比UDC漏洞最终被Pixel修补，但所有其他Android用户收到更新还需要一些时间。这是因为移动更新受到多种因素的限制，包括运营商批准，而且并非所有OEM都能及时提供安全更新（如果提供的话）。

Android有一种更新特定系统库的机制，可以绕过此过程，称为APEX。通过APEX打包的库可以由Google直接通过Google Play商店更新，从而实现更快的更新周期。由于UDC不是作为Android的一部分发布的，因此不具备此功能，尽管通过重大的许可和发布所有权变更可以改变这一点。

结论

审视像我们开发的这种0点击漏洞利用链，很容易将其视为一项独特的技术壮举，而它真正揭示的是目前许多攻击者所具备的能力。虽然开发漏洞利用耗时且需要特定的技术知识，但只要有足够的投入，没有什么是不可能实现的。综合考虑，我们对所需投入之少感到惊讶。

人们也可能倾向于将此漏洞利用视为一系列深奥、难以检测的错误，但确实有一些行动可以降低此类漏洞利用的风险，包括分析和减少0点击攻击面、持续测试安全缓解措施、快速修补以及投资于内存缓解措施。

当今大多数活着的人都将他们的隐私、财务福祉，有时甚至是人身安全托付给移动设备。有许多措施可以用来保护他们免受最危险的对手的侵害。厂商应采取行动，降低平台内存损坏漏洞的风险，并在合理的时间范围内向用户提供安全补丁。