声明三个通道，写入四个：一次零点击 iMessage 漏洞的完整复盘

幻泉之洲

2026年10月10日 10:18
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

本文记录一次真实的零点击漏洞挖掘过程：Apple 的 OpenEXR 解码器按三通道 RGB 分配缓冲区（12 字节/像素），却按四通道 RGBA 写入（16 字节/像素），每像素多写 4 字节，在 448×448 的图片上就变成约 800KB 的堆越界写。作者把这条静态分析线索做成了可控写原语，再找到 iMessage 附件在后台索引与缩略图生成时的自动解码路径——用户不点、不看、不打开，漏洞照样触发。已修复为 CVE-2026-86869。

过去十年里，每一台被真正打穿的 Apple 设备，底下都坐着一个无聊的人。不是钓鱼链接，也不是偷来的密码，而是一个你从没启动过的守护进程，解码一个你从没打开过的文件，然后在一个缓冲区末尾多读/多写了一个字节。

这次的故事就是这一类。它开始于某个深夜的一台 fuzzer——那玩意儿连 EXR 是什么都不知道——结束于一个堆溢出，在 iMessage 落地的那一刻、在通知横幅还没滑完的时候，就在一个有特权的 Apple 守护进程里炸开。不用点。零点击。

为什么零点击才是全部

攻击性安全这行里，吓人程度是有等级的，刻度就是\"点击次数\"。

需要受害者下载 App、运行、再点掉三个警告的漏洞，不值几个钱。需要他们打开附件的，贵一点。需要他们点一个链接的，开始有意思了。然后是最顶上那一档：受害者什么都不用做。文件到了，系统因为\"这就是它的工作\"而去处理它，然后它炸了。这就是零点击。Pegasus 就是靠这一类漏洞，在记者的手机里住了好几年。

零点击之所以贵，是因为现代手机在你没开口的情况下，自动替你做了一大堆事。一张照片出现在 Messages 里，系统想给你显示缩略图，于是解码它；想给它建搜索索引，于是再解码一次；想知道它是不是截图、是不是收据、有没有人脸，于是又丢给几条分析流水线。每一步都是一个解析器在碰攻击者控制的字节，而且跑在权限比\"接收文件的那个沙箱 App\"高得多的守护进程里。你什么都没打开，机器替你全开了。

所以找零点击漏洞，其实是在同时找两样东西：第一，解析器里的内存安全缺陷；第二，一条不需要人参与就能抵达那个解析器的路径。很多人能找到第一样，但一辈子找不到第二样。这篇文章的重点，是我两个都找到了，而且藏在一个几乎没人会多看一眼的格式里：OpenEXR。

EXR 来自视觉特效行业，是个高动态范围图像格式。光用 32 位浮点存，通道数可以任意指定，冷门、复杂、没人审——正好是最适合藏好漏洞的角落。Apple 自己实现了一个解码器，libAppleEXR.dylib，接在 ImageIO 上。这意味着它挂在 CGImageSource 那个漏斗后面，而这个漏斗负责解平台上几乎所有的图片。EXR 在这儿能解，就在任何 ImageIO 被要求打开图片的地方都能解。先把这句话记住。

60 秒看懂这个漏洞

Apple 的 EXR 解码器分配目标缓冲区时，按三通道 RGB 图算大小。每像素 12 字节：红、绿、蓝，各一个 32 位浮点，各 4 字节。合理，因为文件里写的就是 RGB，没有 alpha。

然后它调用一个交错（interleave）例程来填这个缓冲区，而这个例程每像素写四个通道。16 字节：红、绿、蓝，再加一个硬编码的 alpha，值恒为 1.0。它每写一个像素，就比预留的空间多 4 字节。

就这。分配器被告知 12，写入方干了 16。每像素溢出 4 字节，一行一行累积，直到整张图写完。一张 448×448 的图，意味着大约 800KB 的堆数据，被直接写过一个差不多 800KB 的分配块，糊到分配器后面给别人的东西上。

// 分配器被告知的大小（转述自 EXRReadPlugin::decodeBlockAppleEXR）
size\_t bytes\_per\_pixel = channels \ sizeof(float);   // channels == 3  ->  12
dst = malloc(bytes\_per\_pixel \ width \* height);       // 按 RGB 分配

// 写入方实际做的事（CompressedInterleave4）
// 输出 R、G、B 和一个常量 alpha 通道，4 个 float == 每像素 16 字节
// 16 > 12，一直如此，对图中每一个像素都是

真正让它从\"崩溃\"升级成\"武器\"的，是那 16 字节里的 12 字节。红、绿、蓝三个值直接来自文件里的像素数据——攻击者说了算。只有那 4 字节 alpha 是固定的，就是内存里的 0x3f800000。所以这不是普通溢出，而是每覆盖一个机器字，四分之三的内容由我挑的溢出。

剩下的部分，讲我怎么从\"fuzzer 吐出一个奇怪的崩溃\"走到\"我能在真机上、零次点击地操控那 800KB\"。

起点是一台不知道 EXR 是什么的 fuzzer

我并没有某个早上坐下来决定审计 EXR 解码器。没人这么干。呃，除了我。

我的挖掘流程重度依赖 LLM 引导的 fuzzing。原理不复杂：与其对着解析器扔随机字节然后祈祷，不如让模型去读目标函数的反汇编，说出它信任哪些字段，再提出既能保持文件结构合法、又能精确戳到那些 count、size、type tag 的变异。对 EXR 这种格式做纯随机 fuzzing 是白费力气——解码器在前一百个字节就把畸形文件扔了，你根本摸不到有意思的代码。保结构、锚定反汇编的 fuzzing 才能钻得深。

第一个产物不是漏洞，是静态证据。模型啃 libAppleEXR.dylib 的时候，光看代码就标出了一处不匹配：一边是按通道数算出来的分配大小，另一边是附近一个 SIMD 存储循环，步长对不上这个通道数。这不算崩溃，算一个假设。而静态假设十有八九是错的——编译器会做怪事，缓冲区可能在上游被重新调整，那条路径可能根本不可达。我有一条用血泪换来的硬规矩：静态的不对称只是线索，在被运行时真正绊倒之前，什么都不是。

但这条线索质量不错，因为它是最古老的那类图形漏洞：通道数混淆。RGB 进去，RGBA 出来。于是我构造了能驱动这条可疑路径的最小 EXR 文件——448×448，三个浮点通道，ZIP 压缩——用一行代码的测试程序喂给 ImageIO，然后盯着看。

它崩了。

$ ./decode test\_marker\_448x448.exr
Segmentation fault: 11

段错误不是漏洞，是邀请函。该去读残骸了。

读残骸

崩溃报告把出错点放在模型指出的那个函数上，名字一看就是模板生成的：

CompressedInterleave4+452

出错的指令是一条 ARM NEON 存储：

; 就是这条指令在越界写
st2.4s  { v3, v4 }, [x17], #32     ; 交错存储，32 字节，x17 后自增

st2.4s 是\"两寄存器、四通道、32 位交错存储\"。翻译成人话：它把两个向量寄存器的通道交织在一起，往 x17 指向的地方写 32 字节，然后把 x17 往前推 32，准备下一轮。x17 就是横穿目标缓冲区的写游标。循环一步步把它往前推，每次 32 字节，打包四通道像素，一路越过那个\"每像素 12 字节\"的分配块，进入堆的下一个区域。

我把整个循环拆开，确认写进去的是什么，同样重要的是，没写进去的是什么：

• 三条输入流用 ldr 从解压后的 R、G、B 平面读出，也就是文件里的像素值。
• 第四个通道从一个常量加载，就是那个 0x3f800000 的 alpha 哨兵，浮点 1.0。
• 通道用 zip 交织、用 xtn 收窄，最后用 st2.4s 写出。
• 关键在于：没有 ld2 去读相邻的堆内存，没有泄露。这是纯粹的写原语。它从不读邻居，只是砸邻居。

最后一点后来很重要。这种结论只能靠读真实指令得出，不能信崩溃摘要。只写不读，直接决定了哪些利用思路根本不用考虑。

崩溃报告里的出错地址，正好落在映射区末尾再往后一字节。不是空指针解引用，不是野读，是一次干干净净地走出真实分配块的边界。解码器确实按三通道分配了缓冲区，也确实写了四通道。静态假设，此刻成了运行时事实。

但一个事实只够变个魔术。在它值得占用任何人时间之前，我还得知道两件事：我能不能控制那些字节落在哪、写成什么？以及，我能不能在没人礼貌地双击我文件的情况下抵达这个解码器？第一个问题要求我停止崩溃、开始做实验——意味着我得跑几百次而不发疯。

AppleScript 加上死磕搭起来的测试台

要摸清一个堆溢出的脾气，你得一遍又一遍地触发它，每次改一点点条件，然后看什么变了。不同的图像尺寸把溢出推得远近不同；不同的像素值改变写出的字节；事前的不同分配模式改变旁边坐着谁被砸。你在做一个实验设备会主动段错误的科学实验。

我希望这个循环尽可能紧，同时尽可能真实。在自制测试程序里验证机制没问题，但测试程序会骗人：它跑在错误的权限下、错误的分配器状态里、错误的进程中。真正要紧的漏洞，是真实系统触发时的那个漏洞。所以我直接驱动真实应用，在 macOS 上干这件事的胶水就是 AppleScript。

AppleScript 用来干这个堪称又妙又荒诞。它让我能指挥真实操作系统按处理真文件的方式处理我的文件：把一个构造好的 EXR 丢进流水线，让真正的\"照片\"应用去导入它，让真正的解码路径跑起来，收走掉出来的崩溃报告，改一个参数，重来。一个概念上像这样的循环：

-- 驱动真实的导入路径，而不是玩具测试程序，然后收集掉出来的东西
repeat with variant in craftedImages
    tell application \"Photos\" to import (variant as POSIX file)
    delay 2
    -- 抓取这次解码产生的新崩溃报告，和输入绑在一起，重置，继续
end repeat

一圈又一圈，好几个小时。构造、投喂、观察、调整。每一轮都让我多懂一点这个洞的形状：某个尺寸能伸到多远，我能落在堆的哪些区域，落点有多确定。这就是故事里\"一直推下去\"的部分，它主要是耐心。漏洞不会主动把控制权交给你，你只能一次一个无聊的迭代去测绘它的行为，直到图像成形。

图像确实成形了。其实是两张，而第二张让我坐直了。

从\"它崩了\"到\"字节归我管\"

第一张图讲的是\"操控\"，来自堆本身。如果你分配一大坨同样大小的对象，隔一个释放一个，打开可预测的空隙，然后触发一次\"分配 + 溢出\"，溢出就会落进一个你事先安排好邻居的槽位。经典的堆风水。目标缓冲区的大小由图像尺寸锁定，邻居由手工布置，落点就变得确定：每一次运行都是同一个槽位。溢出不再是随机的破坏行为，而是一次写进我选定位置的可控写入。

接着我确认了那里到底能写什么，也是在这里，一个平淡的溢出变得相当难看。我做了一批 EXR 文件，除了像素值以外完全一样，逐个解码，再把溢到邻居对象里的字节读回来。它们跟着我的输入走。喂一个像素值进去，看对应的字节出现在被砸的邻居里。这个关系经过了解码器的色调映射运算，所以不是原样拷贝，但它是一个稳定的、可逆的映射：想让受害者对象里出现某个字节，就反推出能产生它的像素值，把那个值放进文件。

写入不是完全任意的。那个固定的 alpha 通道，0x3f800000，会以可预测的偏移落在每个被覆盖的像素里，我改不了它。但每四字节里有三字节是我的。对攻击者来说，四分之三可控、落点确定，这不叫\"限制\"，这叫\"原语\"。

还有第二条路径扩大了打击面：不是只有\"给我显示缩略图\"这条链会用那个危险选项解码。任何要求输出标准动态范围（SDR）结果的 EXR 转换流水线，同样会触发。打开文件、要求转出 PNG 或 JPEG，解码就会在途中经过同一个溢出例程。这是巨大的攻击面——在现代操作系统上，格式转换时时刻刻在发生，而且看不见。

于是问题回到真正决定成败的那一条：这些全都还是我在给自己的机器喂文件。谁都能弄崩自己的电脑。还有谁在喂这个解码器？我能不能在不用问任何人的情况下够到他们？

下实验台，上真 iPad

要老实回答\"这到底够不够得着\"，就得停止在你开发用的机器上测试，因为你的开发机是脏的。上面有你的工具链、你放松过的设置（关了 SIP 的举手）、你的肌肉记忆。真正要紧的漏洞，是那个在一台属于普通人、从没听说过你的原厂设备上的漏洞。真正的受害者。

所以我在外部准备了一台干净的 iPad 当受害者。上面什么都没有：登录一个全新的 iCloud 账号，默认设置，一个真实目标该有的配置。从那一刻起，只有远程攻击者真能发过去的东西，才允许碰到这台设备。如果我能用攻击者掌控的渠道让它在那边炸开，它就是真的；如果只能靠我上手折腾 iPad 才炸，那它就是个实验室里的怪东西。

▲ 乱糟糟的测试台：一台可怜的 iPad 架在支架上，我那台老 Cynthion，还有一杯凉掉的饮料——它替我崩了一遍又一遍。

真机上的第一个里程碑几乎平淡无奇，但又让人心跳加速：解码器在通过正常途径抵达的文件上炸了，不只是我手放进去的文件。系统自己的图像机制，在对新到内容做日常自动处理时，直接走进了溢出。从那台设备上收集到的崩溃报告不在我的测试程序里，而在 Apple 自己的进程中，出错函数是 CompressedInterleave4，还是那个 +452 偏移，出错地址在一个真实堆区之后一字节。和最早工作台上那次崩溃一模一样的特征，现在发生在一台我只是不断往里发东西的设备上，发生在受信任的系统组件里。

这就是线索变成漏洞的那一刻。不是它在你自己桌上崩的时候，而是它因为\"你发过去的东西\"在别人设备上崩的时候。

接下来是最后也是最好的一个问题：受害者最少要做到什么程度才会中招？因为\"通过正常途径抵达\"仍可能意味着他点了什么。我要的是零。

零点击

一条带附件的 iMessage 到达时，在你决定要不要看一眼这条对话之前，一整条流水线就已经开动了。消息被接收，附件写到磁盘。系统给它建索引，好让它出现在搜索里。索引的一部分工作把内容交给照片子系统，而照片子系统想给它见过的所有媒体编目、准备素材，包括生成缩略图和衍生图片，好让图库保持快速、可搜索。

缩略图生成这一步就是陷阱。在照片库后台的清理进程深处，那段为\"传入的联播内容\"准备衍生图的代码，构造图像解码请求时把 SDR 选项硬编码打开。不是有条件的，是无条件的。而这正是那个把 EXR 解码器切进\"写四通道、冲垮缓冲区\"路径的选项。于是顺序是这样：

1. 一条带 EXR 附件的 iMessage 到达，附件落盘。
2. 持久化和索引机制把它吃进去，转发给照片子系统。
3. 一个后台 worker——本来只是为了让你的图库保持整洁——决定为新内容生成衍生图片。
4. 它构造了一个 SDR 选项硬编码打开的解码请求。
5. ImageIO 把 EXR 路由给 libAppleEXR，后者回答\"能，这个请求我能满足\"，然后跑解码。
6. CompressedInterleave4 在那个有特权的后台守护进程里，把每像素 16 字节写进每像素 12 字节的缓冲区。

没有人打开 Messages，没有人点附件，甚至没有人看过那条通知。溢出之所以触发，是因为操作系统在做它被设计来做的事——替受害者解码文件——而那个进程的权限，比最初接收文件的沙箱大得多。

说这确实是\"无交互\"，证据一直躺在崩溃报告里。几份真机崩溃被标记为发生在后台处理中，在联播和导入机制里，发生时前台什么都没有，也没有人碰设备。解码路径里的后台模式崩溃，就是收据：是机器触发的，不是用户。

你可能会问 BlastDoor。Apple 造它就是专门防这个的：一个锁死的沙箱，在远离一切有价值东西的地方咀嚼不受信任的 iMessage 内容，是上一代零点击附件漏洞之后加上的。它怎么就被绕过去了？两个原因。EXR 不在 BlastDoor 处理类型的清单上，所以 BlastDoor 根本不解码这个文件。而真正要紧的那次解码压根不发生在消息解析路径里——它发生在之后、发生在另一个守护进程里，当保存下来的附件被建搜索索引、照片库悄悄生成缩略图的时候。BlastDoor 守的是前门，这个漏洞从标着 Spotlight 的侧门走了进来。

这就是一条从附件出发、经 iMessage、跨过互联网、零点击打入 Apple 特权守护进程的路径。

而且这不是 macOS 专属的故事。libAppleEXR 和 ImageIO 在 iOS、iPadOS、macOS 上是同一份代码，为同一块 arm64e 芯片编译。CGImageSource 漏斗一样，SDR 解码选项一样，处理传入附件的图库缩略图和联播机制三个系统上都有。本文的复现碰巧在 Mac 上跑、在 iPad 上确认，但那条出错的指令和它的零点击可达性，是跨平台的。同一个构造好的附件，落在 iPhone、iPad 还是 Mac 上，触发的都是同一个溢出。

到底有多严重，说实话

现在说老实话的部分——夸大严重性，是失去上报对象（尤其是一线分诊人员）信任的最快方式。

我能证明的是：一次零点击触发的、受控的堆溢出，发生在特权守护进程里。落点确定，四分之三字节由攻击者控制，可经 iMessage 抵达且无需交互。这本身就是个严肃的原语，它彻底击穿了\"必须先骗用户\"这个假设。

然后我继续推，原语以更要命的方式变坏了。448 像素下的线性溢出会冲进未映射的守护页，所以早期崩溃都是干净的段错误。但把构造缩小、让目标落进 small / tiny 分配区，再把邻居布置到位，这个写就不再是钝器式的越界，而是 write-what-where：往我选的地址写一个字节。证据朴素但彻底——一次崩溃的出错地址是 0x67e03bd12a4a594e，这既不是堆指针也不是 slide，而是我挑的值，我把写导向了它。这是任意写，不是\"恰好落在某处\"的溢出。

从任意写往上走一级是控制程序计数器。在受控的测试环境里它稳定成立：改一个函数指针槽位、触发、执行流转到我瞄准的地方，100 次跑 100 次中。所以\"这能不能到代码执行\"不是含糊其辞，在测试环境里它就是代码执行。

诚实的褶皱在从测试环境跨进程边界到真实受害者这一步，而这是现代 Apple 芯片挣回脸面的地方。指针认证（Pointer Authentication，PAC）会给你要劫持的函数指针签名，你没法凭空伪造一个合法目标。没有单独的信息泄露把 PAC 交到我手上，PAC 就守得住，干净、无辅助的跨进程突破就非常难受。还有第二道缓解在真干活：零点击路径里的那个特权守护进程，在最新芯片上开启了硬件内存标记，所以在那些芯片上溢出会触发标签检查故障，而不是静默破坏。这一轮你赢了，M5。

但是，诚实而不舒服的另一半是：同样的标记在前台\"照片\"进程上并没开，而所有非最新一代的设备压根没有这种硬件标记。在那海量的设备上，这个写不会触发任何东西。它就是发生了。所以\"内存标记能抓住它\"这句话，只对最新硬件上的某一个进程成立，对其它所有能抵达这个漏洞的地方都是假的。这个溢出在完全关闭标记的硬件上也会一模一样地触发——同一条指令，同一类故障——这恰恰证明漏洞本身在解析器层面，任何一代芯片都救不了它。

所以诚实的天花板是：一条经 iMessage 抵达特权守护进程的、零点击、攻击者可控的写，可升级为任意写和测试环境级的程序计数器控制，最后一步跨进程被 PAC 签名的指针挡住。Apple 的分诊把这份报告归类为\"通过 iMessage EXR 图片载荷实现的零点击代码执行\"，并发布了修复。

给防御方

如果你在构建或防守这类系统，几条具体的东西：

你的解析器在你不看着的时候也在跑。现代操作系统上最吓人的攻击面，不是用户操作时才运行的代码，而是内容一到就自动运行的代码：缩略图生成器、索引器、媒体分析器、预览生成器。把这些路径盘一遍。每一条都是一个解析器，在提升后的权限下吃着敌意字节，前面没有任何人的关卡。

冷门格式是漏洞退休的地方。JPEG 和 PNG 已经被 fuzz 烂了，没人看 EXR，也没人看通用图像漏斗悄悄支持的那十几种冷门格式。攻击面由\"代码能解什么\"定义，不由\"用户平常发什么\"定义。只要 ImageIO 能打开它，它就在范围内，而那些冷门角落得到的审视最少，藏的好东西最多。

分配器和写入方必须达成一致，而且得有人强制它。这个漏洞就是同一个数字在两处分歧：分配时三个通道，写入时四个。一条断言——写入步长必须等于分配步长——就能把 800KB 的溢出变成一次干净、安全的中止。把\"缓冲区按什么大小分配\"和\"按什么大小写入\"绑起来的防御性检查很便宜，而且正好抓住这一整类问题。

后台守护进程里的崩溃是安全事件，不是稳定性小毛病。那些后台模式的崩溃报告，是最响亮的信号：不受信任的内容正在抵达敏感解码器，而且中间没有人。把\"联播 worker 在图像解码器里段错误了\"当噪音处理的遥测，是在把警报扔掉。

给漏洞猎人

如果你站在进攻这一边，几条我觉得有意思的经验：

静态不对称只是线索，永远不是结论。通道数不匹配在反汇编里看得见，但大量看得见的不匹配是不可达的、被上游夹住的、或者被编译掉的。它在运行时、在真实进程、在真实目标上摔倒之前，一文不值。要爱上崩溃，别爱上假设。

可达性是一半的漏洞，通常还是更难的那一半。找到这个溢出花了一天读汇编。找到一条不需要交互就能抵达它的路径花的时间长得多，也重要得多。谁都能弄崩一个自己喂文件的解析器。价值全在于还有谁在喂它，以及他们喂的时候有没有问过受害者。时间要按这个比例分配——多数人在原语上投入过度，在可达性上投入不足。

在真实进程里测，并且不要相信自己的结果。测试程序会在分配器状态、权限和可达性上痛快地骗你。那套驱动真实系统应用的 AppleScript 台子告诉我的东西，任何独立二进制都给不了，因为它走的是真正的导入路径，旁边是真正的堆。

只声称你证明了的，一点也别少。我报的是一个受控的零点击溢出，然后持续升级它：任意写，测试环境里的程序计数器控制，再到被 PAC 签名指针挡住的跨进程控制。把每一级台阶精确命名——包括我没干净跨过去的那一级——比四舍五入成\"完整 RCE\"，或者同样糟糕地缩水成\"只是个崩溃\"，都更可信。精确是双向的：别超过你实际跑出来的，也别把一个真实原语折成比它该得的更小的词。

披露时间线

最新版本上已经修了，但还停在旧 iOS、iPadOS、macOS 上的那支庞大舰队，在每台设备真正更新之前都不会停止脆弱。所以这篇文章刻意把文件构造细节和堆风水配方停在概念层面。

收尾

这整趟航程和每一次经典的移动端攻陷都押着同一个韵脚，而这就是那堂课。它不是一个聪明的社工技巧，也不是泄露的凭据。它是一个解析器读了一个文件，然后信了一个数字。声明三个通道，写入四个通道，两个事实之间每像素 4 字节的缝隙，长成了 800KB 的可控堆覆写。没人审计的冷门格式，经由没人盯着的自动机制抵达，在没人料到会被波及的特权守护进程里炸开，而被攻击的人一次都没点。

内存安全缓解是真的，也确实在变好。PAC 实实在在抬高了把它变成代码执行的成本，硬件内存标记也确实在唯一开启的地方抓住了这个写。但缓解保护的是\"选择开启它的进程\"和\"出厂带它的硬件\"，而剩下那条长长的尾巴，正是漏洞还能干净咬下去的地方。一个只覆盖最新芯片上某一个守护进程的缓解，没有覆盖舰队。

从文件开始，顺着它找到解析器。然后——这一步才是区分\"一个崩溃\"和\"一次攻陷\"的地方——顺着解析器找到所有在没问过用户的情况下喂它的人。零点击就住在那一步里。

顺风，各位同行。看好你的附件。

来源与延伸阅读

• OpenEXR 文件格式（https://openexr.com/）：格式规范，这个漏洞所处的通道与压缩模型。
• Apple ImageIO / CGImageSource（https://developer.apple.com/documentation/imageio）：平台上每一张图片（包括 EXR）都要过的解码漏斗。
• Pardon MIE?：我早前关于 Apple Memory Integrity Enforcement 的文章，对应上文提到的内存标记与 PAC 背景。
• Crouching T2, Hidden Danger：同一族\"信得太多\"漏洞的早期 Apple 硬件安全工作。