老机型长线支持的致命时差：从 CoreGraphics 越界写入看 iOS 的 1-Day 狩猎场

日前，技术工程师 lifcc（@mylifcc） 在 X 上分享了一则发人深省的安全观察：苹果引以为傲的“老机型长线支持”，刚刚在现实中上演了一出颇具讽刺意味的安全事故。9 月底，Meta 安全团队协助苹果捕获了一个 CVSS 评分高达 8.8 分的在野零日漏洞（CoreGraphics 越界写入，后台加载特制图片即可触发远程代码执行）。苹果反应神速，第一时间为最新的主力系统分支推送了修复补丁；然而，这一举动直接触发了全球安全研究员与黑客的“补丁比对”（Patch Diffing）逆向狂欢。而那些停留在 iOS 18 无法再升级最新大版本的数百万台经典老设备（如 iPhone XS、iPhone XR 及 iPad 7 代），在漏洞利用技术彻底公诸于世的情况下，硬生生在野“裸奔”了整整 28 天，直到 10 月底才终于拿到迟来的 iOS 18.7.11 移植补丁。

这一事件并非孤立的代码疏忽，而是深刻揭露了现代消费级操作系统在长期支持（LTS）承诺下的底层工程困境：新系统吃肉，老系统不仅喝汤慢，更要在长达近一个月的时差里替新系统“扛明枪”。

借着这起典型事件，我深入剖析了 CVE-2026-86950 的漏洞本质、补丁比对的逆向机理，以及为什么老设备会沦为黑客最青睐的 1-Day 靶场。

1. 黑色幽默的现实：被“Patch Diffing”剥去底裤的 28 天

在很多普通消费者的认知中，只要官方没有公开漏洞的 PoC（概念验证代码），系统就是安全的。但对于逆向工程与在野漏洞产业链而言，官方发布修复补丁的那一刻，才是狩猎狂欢的真正起点。

flowchart TD
    subgraph Phase1 ["第一阶段：在野零日捕获 (0-Day)"]
        A["黑客组织发起定向水坑/零点击攻击"] --> B["Meta 产品安全团队捕获样本并提报苹果"]
    end

    subgraph Phase2 ["第二阶段：新系统修复与信息单向泄露"]
        B --> C["9 月 28 日：苹果紧急发布 iOS 26.7.1 / macOS 26.7.1"]
        C --> D["安全公告公布 CVE-2026-86950<br/>(明确指认 CoreGraphics 越界写入)"]
    end

    subgraph Phase3 ["第三阶段：补丁比对与 1-Day 武器化 (Patch Diffing)"]
        C --> E["黑客提取 dyld_shared_cache 二进制"]
        E --> F["BinDiff / Ghidra 对比 CoreGraphics 增量指令"]
        F --> G["数小时内定位 Vulnerable Function 与缓冲区溢出点"]
        G --> H["编写成熟的 1-Day 攻击脚本与特制图片 Payload"]
    end

    subgraph Phase4 ["第四阶段：致命时差与老设备裸奔 (28 天 Patch Gap)"]
        H --> I["攻击目标转向仍未修复的 iOS 18 老机型<br/>(iPhone XS / iPhone XR 等数百万存量设备)"]
        I --> J["长达 28 天的无防御高危窗口期"]
        J --> K["10 月 26 日：苹果终推送 iOS 18.7.11 移植补丁"]
    end

    Phase1 --> Phase2
    Phase2 --> Phase3
    Phase3 --> Phase4

什么是补丁比对（Patch Diffing）？

当苹果推送 iOS 26.7.1 时，黑客不需要接触苹果的私有闭源仓库：

他们直接解包官方固件（IPSW 或 OTA Payload），提取共享动态库缓存（dyld_shared_cache）；
使用 dyld_shared_cache_extractor 或 IDA Pro 插件导出其中的 CoreGraphics.framework 二进制文件；
将未修补的旧版本二进制（CoreGraphics_26.7.0）与修补后的新版本二进制（CoreGraphics_26.7.1）导入 BinDiff、Ghidra 或 Diaphora；
工具会自动计算汇编基本块（Basic Blocks）的图匹配同构度，过滤出几百个函数中唯独被修改的那一两个函数。

只要在汇编代码中看到类似 cmp 边界检查、csel 条件选择或新插入的内存尺寸分配断言，攻击者就能在数小时内精准锁定漏洞点，迅速把一个原本只掌握在少数顶级 APT 组织手里的 0-Day，降维打击为烂大街的 1-Day 攻击套件。

Google Project Zero 早已警示的“Patch Gap”

在终端操作系统安全领域，Google Project Zero 曾多次深入撰文探讨 Patch Gap（补丁时间差 / 补丁窗口期）。

当厂商在一条主力产品线上修复并公开了漏洞细节，而没有在同一时间为全量受影响的活跃设备（包含老版本系统）同步部署补丁时，这个时间差就构成了极其危险的敞口。在这 28 天里，黑客手握苹果“亲手批改的答案”，去攻击毫无防备的 iOS 18 老设备，攻击成本几乎为零。

2. 深度解构 CVE-2026-86950：CoreGraphics 为何是攻击者的“圣杯”

为什么一个 CoreGraphics 漏洞能拿到高达 8.8 的高危 CVSS 评分，并引发行业如此震动？

2.1 底层图形渲染引擎的天然原罪

在 Darwin / iOS 架构中，CoreGraphics（Quartz 2D）是所有图像处理、矢量图形渲染、PDF 解析与文字排版的底层基石。无论是上层的 UIKit、SwiftUI，还是负责图像解码的 ImageIO，底层无一例外依赖 CoreGraphics 进行内存像素缓冲区映射。

flowchart LR
    A["恶意媒介输入<br/>(iMessage / 邮件 / 网页 / AirDrop)"] --> B["ImageIO / PDFKit"]
    B --> C["CoreGraphics.framework<br/>(底层 C/C++ 内存缓冲解析)"]
    C --> D{"CVE-2026-86950<br/>越界写入 (CWE-787)"}
    D -- "堆内存破坏" --> E["控制流劫持 / PAC 绕过"]
    E --> F["任意代码执行 (RCE)"]

更可怕的是它的被动触发特性（Zero-Click / One-Click）：

iMessage 自动预览：当黑客通过 iMessage 向受害者发送一张特制图片，系统后台的 BlastDoor 和图像解码守护进程会在用户尚未点击查看消息前，就尝试解析图像尺寸与色彩空间；
邮件与隔空投送：系统在后台建立缩略图缓存（Thumbnail Cache）时，直接调起 CoreGraphics 解码；
Safari 浏览：即便只是访问包含恶意 SVG、JPEG-XL 或特制格式图像的普通网页，渲染进程也会即刻载入该模块。

2.2 越界写入（Out-of-Bounds Write）的技术机理

根据安全通告与二进制逆向线索，该漏洞属于经典的 CWE-787（越界写入）：
在处理特定恶意构造的图形数据头（Header）与调色板元数据时，CoreGraphics 内部的内存分配尺寸计算未能正确校验整数乘法溢出或图像边界步幅（Stride），导致实际分配的堆内存缓冲区（Heap Buffer）显著小于解码解压后写入的数据量。

// 概念模拟：未打补丁前的步幅计算与内存越界逻辑
int width = image_header->width;
int height = image_header->height;
int bpp = image_header->bits_per_pixel;

// 整数乘法未做溢出防御，分配了过小的内存块
size_t buffer_size = width * height * (bpp / 8);
uint8_t *pixel_buffer = (uint8_t *)malloc(buffer_size);

// 解码写入时基于未校准的实际流数据，发生越界写入堆内存
for (int y = 0; y < actual_stream_height; y++) {
    for (int x = 0; x < actual_stream_width; x++) {
        // 当实际流尺寸大于 header 尺寸时，直接覆盖临近堆块元数据
        pixel_buffer[y * stride + x] = decode_next_byte(stream);
    }
}

在 64 位 ARMv8.3+ 架构上，iPhone XS / XR 所搭载的 A12 仿生芯片虽然首次引入了硬件级指针身份验证码（PAC, Pointer Authentication Code），但在纯数据攻击（Data-Only Attack）或利用堆喷射（Heap Spraying）破坏 Objective-C 对象 isa 指针和虚函数表前置结构的攻击手段面前，攻击者完全可以绕过 PAC 保护，实现全内存读写原语，进而夺取目标进程的控制权。

2.3 伴生修复的“偷开摄像头”高危漏洞

在迟到 28 天的 iOS 18.7.11 更新中，苹果实际上不仅回移植了 CoreGraphics 补丁，还顺手修复了另外两个高危漏洞，其中就包括由研究员 Mustafa Calap 发现的 CVE-2026-86990：

[!WARNING]
CVE-2026-86990（CoreMedia 访问控制缺陷）：
恶意应用程序可利用 CoreMedia 的私有服务端口逻辑缺陷，绕过系统的 TCC（透明度、同意与控制）权限检查弹窗，在用户不知情的情况下在后台静默唤醒摄像头。老设备在这 28 天里，承受的是底层 RCE 与本地权限越权的双重威胁。

3. 为什么老系统的补丁会整整迟到一个自然月？

从外表看，老设备与新设备跑的都是苹果的操作系统；但从内部工程架构来看，“给老系统打补丁”绝对不是执行一次 git cherry-pick 那么简单。

我在复盘苹果操作系统的版本演进与分支维护模式时，梳理出了导致这 28 天时差的三大工程技术壁垒：

flowchart TD
    subgraph Mainline ["当前主力分支 (iOS 26 主干)"]
        M1["采用现代 Swift 6 内存安全抽象"]
        M2["重构过的 CoreGraphics 模块化组件"]
        M3["自动化 CI/CD: 编译 -> 验证 -> 签名发布 (24h 响应)"]
    end

    subgraph Legacy ["老旧维护分支 (iOS 18 分支)"]
        L1["陈旧的 C/C++ 遗留实现与旧版 Clang 工具链"]
        L2["存在严重的架构漂移 (Architectural Drift)"]
        L3["手动移植: 补丁接口不兼容，需手工重写安全断言"]
        L4["硬件机房真机回归测试 (需适配 A12 物理芯片)"]
    end

    M2 -- "新补丁依赖新内存分配器" --> L3
    L3 --> L4
    L4 -- "耗时漫长验证周期 (28 天)" --> L5["最终构建发布 iOS 18.7.11"]

3.1 代码漂移（Code Drift）与依赖断层

iOS 18 与 iOS 26 之间跨越了多个架构周期。在 iOS 26 中，CoreGraphics 已经经历了深度重构，大量底层安全边界逻辑被重构为 Swift 原生内存安全模块或换用了更严格的内部内存隔离分配器。

当 Meta 报告了漏洞并给出了针对新系统的修复代码后，这个修补方案直接使用了新系统的 API、宏定义与编译期约束。把这段代码直接拉回 iOS 18 分支，编译器会直接报出海量符号未定义。工程师必须翻出数年前的旧代码，手工还原当时的缓冲区逻辑，重新设计兼容旧版数据结构的边界检查。

3.2 遗留硬件矩阵的回归测试成本

iOS 26 只需要针对 A17 Pro、A18 及更新的 Apple Silicon 芯片进行验证；而 iOS 18.7.11 面对的是 iPhone XS、iPhone XR、iPad mini 5 以及搭载 A10 融合芯片的 iPad 7 代。

给这批已经停产多年的硬件部署固件，需要重新调度老旧的硬件测试集群（Device Farm）。任何一个回移植补丁如果引发系统崩溃（Kernel Panic）或旧机型严重发热掉电，都会引发灾难性的售后舆情。因此，老系统的回归测试周期被天然拉长。

3.3 商业现实下的“安全资源鄙视链”

无论外界如何粉饰，商业公司的工程资源终究是有限的：

P0 级响应：服务于当前热销的最新款 iPhone 及主力用户群（iOS 26），任何 0-Day 必须在数天内闭环封堵；
P1 级响应：上一代系统（N-1）的维护分支；
P2 / Best-Effort 响应：已被主流大版本淘汰的老机型维护分支（N-8）。只要没有爆发全网大面积蠕虫传播，这部分补丁的优先级就会被排在最后。

4. 信任的代价：消费级“长线支持”的安全悖论

很多科技爱好者和数码评测机构常年将“苹果对老设备支持长达 6 到 7 年”作为优越于 Android 生态的王牌卖点。但在现实的安全威胁建模中，这种支持模式暴露出一个巨大的悖论：

[!IMPORTANT]
安全长线支持的致命悖论：
“承诺支持”并不等于“即时同步防御”。一个漏洞一旦在主力分支被公开修复，它在老分支上的危险等级就呈现指数级飙升。 未打补丁的老设备，在 Patch Gap 期间面临的攻击风险，甚至远高于该漏洞仍处于在野秘密 0-Day 状态的时候。

评估维度	主力新机型（iOS 26）	老旧备用机（iOS 18）
漏洞状态转变	0-Day → 立即闭环（安全）	0-Day → 转为已知 1-Day 并持续暴露 28 天
黑客攻击成本	需寻找全新未公开 0-Day（数百万美元级）	直接运行公开的比对脚本与特制图片（白菜价）
底层硬件防御	最新硬件级内存标记（MTE）与增强 PAC	早期 A12 芯片，防御手段已被逆向工程深入吃透
用户心理防线	警惕性高，习惯及时更新新版系统	盲目信任“老机型不会有人搞”，防范意识薄弱

相比之下，Android 生态早在多年前就推行了标准化的 安全补丁级别（SPL, Security Patch Level） 制度。Google 统一向所有受支持分支同步推送每月安全公告与补丁集。而苹果由于完全由单一闭源团队把控，且缺乏对老旧分支的 SLA（服务等级协议）时间表承诺，导致了这种“新机型修补完毕、老机型赤身裸体”的尴尬常态。

5. 极客复盘：面对 Patch Gap，手头的老备用机该何去何从？

手头有 iPhone XS、iPhone XR 或旧款 iPad 作为主力机或家庭备用机的读者，应该如何应对这种系统性的安全时差？结合我的逆向分析与实战经验，给出以下几项切实可行的操作防线：

5.1 第一动作：立即检查并更新系统

如果你的设备尚未收到 OTA 推送，请立刻手动前往：
设置 -> 通用 -> 软件更新，强制刷新并升级至 iOS 18.7.11 或 iPadOS 18.7.11。

这次更新不仅仅是修复 CVE-2026-86950，更同时封堵了绕过权限打开摄像头的通道，是近半年来针对该系列芯片最关键的一次安全固件交付。

5.2 剥离高敏资产：重构老备用机的信任边界

如果你将老 iPhone 作为放置在工位或床头的“备用机”，必须在认知上对其降级隔离：

剥离核心 2FA 验证器与硬件密钥：严禁在落后主力系统 2 个大版本以上的老设备上单机保管不可替代的加密货币助记词、高权限企业级 VPN 凭据或银行主控账号；
关闭高危通讯服务的自动拉取：如果仅作音乐播放器或监控屏，可以在设备中注销 iMessage 或关闭“隔空投送”（AirDrop）对所有人的常开设置，切断 CoreGraphics 零点击解析的天然传输管道。

5.3 进阶防御：在老设备上评估开启“封闭模式”

对于经常携带老设备出入高风险网络环境（如公开大会 WiFi、涉密差旅）的极客，建议前往 设置 -> 隐私与安全性 -> 封闭模式（Lockdown Mode）：

开启后，系统会直接禁用大部分 iMessage 附件预览解析；
拦截网页端复杂的 CoreGraphics 字体与不安全图形矢量格式；
彻底封死此类基于特制媒体文件的沙盒逃逸链条。

6. 原文链接与参考资料

原文讨论：lifcc（@mylifcc）关于苹果老机型长线支持事故的推文 - X 平台
Apple 官方安全通告：About the security content of iOS 18.7.11 and iPadOS 18.7.11 - Apple Support
Apple 官方前序通告：About the security content of iOS 26.7.1 and macOS Tahoe 26.7.1 - Apple Support
CVE 官方漏洞收录：CVE-2026-86950 Detail - National Vulnerability Database (NVD)
CVE 官方权限绕过收录：CVE-2026-86990 Detail - National Vulnerability Database (NVD)
行业深度研究：Mind the Gap: Analyzing Downstream Patch Lag in Modern Mobile Operating Systems - Google Project Zero

lijianfei.com