协议窥探：AirDrop 与 Quick Share 的漏洞研究

# 系统性的 Apple AirDrop 和 Android Quick Share 邻近传输协议漏洞研究
来源：https://arxiv.org/html/2606.26967

###### 摘要

Apple AirDrop 和 Google/Samsung Quick Share 是邻近文件传输协议，被超过 50 亿台设备使用，然而其应用层安全属性在很大程度上尚未被研究，因为这两个协议栈都是专有且缺乏文档的。这两个协议均可在无需任何事先配对的情况下，通过无线邻近性触及，并在特权守护进程内处理复杂的序列化内容（二进制 plist、CPIO 归档、Protocol Buffers、UKEY2 握手），使其成为跨多个操作系统的有吸引力的零点击攻击目标。我们进行了首次跨平台逆向工程和协议感知模糊测试研究。通过二进制分析，我们重构了 AirDrop 的七层状态机和 DVZip 自适应压缩，构建了 AirFuzz（一种协议感知模糊测试器，可变异压缩前表示），并辅以针对 Samsung Quick Share 服务和 Google Quick Share for Windows 的定向手工分析。我们发现了六个漏洞（V1-V6）：三个 macOS/iOS AirDrop 中的预认证问题（V1：HTTP 路径路由器中的 Swift fatalError 拒绝服务；V2：Foundation 中无界 XML plist 递归；V3：Network.framework 中 HTTP/1.1 解析器的空指针解引用），两个 Samsung Quick Share 中的协议层缺陷（V4：预认证 OfflineFrame 调度；V5：三种帧类型的 D2D 加密绕过），以及 Google Quick Share for Windows 中的一个堆释放后使用漏洞（V6），Google 已为此奖励了漏洞赏金。我们负责任地披露了所有发现，Apple、Samsung 和 Google 已确认收到报告。为透明和可复现，AirFuzz 工件已在 Zenodo 上公开提供：https://zenodo.org/records/20442029。

## 1 引言

基于邻近性的文件传输是现代移动和桌面操作系统的一项基本功能。Apple 的 AirDrop（2011 年引入）和 Google 的 Nearby Share（现为 Quick Share，2020 年推出）共同服务于超过 50 亿台活跃设备 [apple-active-devices, google-android-devices]。这些协议支持附近设备之间通过蓝牙低功耗（BLE）进行发现、通过 Wi-Fi 进行数据传输的临时点对点文件传输，无需共享网络基础设施。

从安全角度来看，邻近传输协议呈现出一个令人信服的攻击面 [beer2020awdl, silvanovich2019zeroclick, gross2020remote, yair2024quickshell, toothpicker]。攻击者只需在无线范围内（对于 AWDL/Wi-Fi Direct 通常为 10-30 米），并且初始协议阶段（服务发现和连接建立）*不需要任何认证*。在配置了“所有人”可见性的 Apple 设备上，整个发现和询问阶段无需任何用户交互或事先配对即可触及。这创建了一个零点击、预认证的攻击面，从特权 sharingd 守护进程（也管理 AirPlay、Handoff、Universal Clipboard 和 Continuity Camera）一直延伸到内核：Beer 的 iOS 零点击无线电邻近性利用 [beer2020awdl] 展示了针对 AWDL 内核驱动本身的远程代码执行，表明攻击面不仅限于用户空间共享代码。

尽管这些协议无处不在且具有安全相关性，但先前的学术工作主要集中在 AirDrop 联系人发现机制的隐私方面 [heinrich2021opendrop, heinrich2021privatedrop, stute2021disrupting, martin2019handoff] 以及底层的 AWDL 链路层。Stute 等人的基础性工作 [stute2018billion, stute2019openwifi, stute2021disrupting] 逆向工程了 AWDL 本身，发布了开源 OWL 协议栈，并展示了链路层拒绝服务和中间人攻击；他们的结果提供了我们应用层分析所基于的无线基板。与此同时，Project Zero [beer2020awdl] 将 AWDL 内核攻击面武器化以攻击 iOS。*应用层* AirDrop 协议（二进制属性列表、DVZip 压缩、CPIO 归档提取以及 sharingd 中的 HTTP 层状态机）的全面安全分析尚未发表。类似地，尽管 Google 的 Quick Share 在其 Windows 客户端的 SafeBreach RCE 链之后受到了关注 [yair2024quickshell]，但 Samsung Android 实现的安全属性在很大程度上仍未得到检验。

在本文中，我们通过系统性的安全分析填补了这一空白，涵盖 Apple AirDrop 和 Android Quick Share。我们的工作做出以下贡献：

1. **AirDrop 的应用层逆向工程。** 基于 Stute 等人的 AWDL 链路层工作 [stute2018billion, stute2019openwifi]，我们在当前的 macOS 和 iOS 上逆向工程了完整的 *应用层* AirDrop 协议栈，记录了从 AWDL 到 DVZip/CPIO 归档提取的七个协议层。我们重构了 sharingd 的接收端状态机，记录了之前未公开的 DVZip 自适应分块压缩格式，并编目了 40 多个协议命令。针对特定二进制版本的详细偏移量、反汇编和符号列表作为工件发布，而非内联复现。
2. **协议感知模糊测试器。** 我们开发了 AirFuzz，一个具有九个变异层（HTTP、二进制 plist、DVZip、CPIO、DER、havoc、memcorrupt 和字段级）以及基于 Frida 的覆盖率收集的协议感知模糊测试器。我们讨论了为何没有使用 FridaStalker、fpicker [fpicker, toothpicker] 或 TinyInst/Jackalope [tinyinst, jackalope, p0-coreaudiod] 作为我们的覆盖率引擎；特别是，我们复现了 arm64e macOS/iOS 上的 Stalker 破坏问题（第4节 (https://arxiv.org/html/2606.26967#S4)）。
3. **AirDrop 漏洞。** 我们发现了两个零点击和一个后接受的预认证漏洞：（V1）HTTP 路径路由器中通过 Swift fatalError 实现的远程拒绝服务，（V2）Foundation 的 XML 属性列表解析器中的栈溢出，以及（V3）Network.framework 中的空指针解引用。
4. **Quick Share 漏洞。** 我们在 Quick Share 中发现了三个漏洞：（V4）帧处理绕过，允许在 UKEY2 握手完成之前进行未经认证的协议交互；（V5）设备到设备（D2D）加密绕过，在 Samsung 的 Android 实现中，7 种握手后帧类型中的 3 种在没有强制 SecureMessage 加密包装的情况下被处理；（V6）Google Quick Share for Windows（版本 1.2.2472.1）中由于端点竞争条件导致的关键释放后使用漏洞，可导致远程代码执行。
5. **跨平台比较。** 我们提供了 Apple 和 Google/Samsung 邻近传输实现的首次跨平台安全比较，识别了跨 macOS、iOS、Android 和 Windows 的六个漏洞中共享的漏洞模式和不同的设计决策。

我们负责任地向 Apple Product Security、Samsung Mobile Security 和 Google Vulnerability Reward Program 披露了所有漏洞。Apple 确认了 V1-V3，修复正在进行中；Samsung 将 V4-V5 转交给了 Google；Google 确认了 V6 并为 Windows Quick Share 释放后使用漏洞颁发了赏金，CVE 正在分配中。第7.5节 (https://arxiv.org/html/2606.26967#S7.SS5) 提供了完整的披露时间线和供应商回应。

##### 漏洞概述。
表1 (https://arxiv.org/html/2606.26967#S1.T1) 总结了六个漏洞、它们的目标组件、到达它们所需的先决条件以及观察到的 impact。我们在整篇论文中将此表作为路线图。

表 1：六个漏洞（V1–V6）概览。Precond.: “Everyone” = AirDrop 处于“所有人可见 10 分钟”模式；“Visible” = Quick Share 对附近设备可见；“On-path” = 同局域网攻击者（仅 V5）；“Race” = 并发连接/断开（V6）。Impact: DoS = 拒绝服务；PoP = 协议状态操纵；UAF = 可能可利用的释放后使用。

## 2 背景

### 2.1 Apple AirDrop

AirDrop 于 OS X Lion（2011 年）和 iOS 7（2013 年）引入，支持 Apple 设备之间的点对点文件传输。它依赖于两种无线技术：*蓝牙低功耗（BLE）*用于初始设备发现和唤醒，以及*Apple Wireless Direct Link (AWDL)* 用于实际数据传输。AWDL 是一种专有的基于 Wi-Fi 的协议，在 awdl0 虚拟接口上使用 IPv6 链路本地地址创建临时的 mesh 网络 [stute2018billion]。AirDrop 的应用逻辑在 sharingd 中实现，这是一个管理多个 Apple 连续性服务的特权守护进程。在接收端，sharingd 在 AWDL 上通过 TLS 监听 TCP 端口 8770，提供 HTTP/1.1 API。该守护进程由 launchd 管理，崩溃时自动重启，但连续失败后会呈指数级增加节流延迟。sharingd 是一个庞大且单一的系統守护进程。在 iOS 18.1/26.3 (ARM64e) 上，二进制文件*已剥离*，通过标准工具仅能看到一个导出符号（_main 和 _mh_execute_header）。它动态加载私有框架 Sharing.framework（3.8 MB，5,032 个导出符号），该框架实现了核心的 AirDrop 协议逻辑，并链接了大约 30 个系统框架，包括 Foundation、Security、Network、CoreFoundation 和 libswift_Concurrency。该守护进程不仅管理 AirDrop，还管理 AirPlay、Handoff、Universal Clipboard、Continuity Camera、NameDrop 和 SharePlay，这意味着任何子系统的崩溃都会同时中断所有连续性服务。

AirDrop 支持三种可见性模式：*接收关闭*（无 AWDL 监听器）、*仅联系人*（需要 Apple ID 证书链验证）和*所有人可见 10 分钟*（接受来自任何设备的连接）。在“所有人可见 10 分钟”模式下，完整的 HTTP  API 无需任何形式的身份验证即可访问。在 iOS 上，Apple 添加了 10 分钟自动超时，将“所有人”恢复为“仅联系人”，但这种缓解措施并不能防止暴露窗口期内的攻击，并且不适用于 macOS。

### 2.2 Android Quick Share

Quick Share（原名 Nearby Share）是 Google 面向 Android、Chrome OS 和 Windows 的跨平台文件共享功能。在 Samsung 设备上，它作为默认共享机制深度集成，取代了 Samsung 早期的“Nearby Share”实现。Quick Share 结合使用了 BLE、Wi-Fi Direct、Wi-Fi LAN，并且根据场景可能还使用 WebRTC。Quick Share 的会话流量主要结构化为 Protobuf 序列化消息（例如 OfflineFrame 族），并且通常通过身份验证密钥交换和加密传输来保护。特别是，对 Quick Share for Windows 实现的逆向工程报告称，在初始 UKEY2 握手之后，后续的 OfflineFrame 包会被加密。[safebreachQuickShareRCE]

从高层次来看，连接生命周期可以分为四个阶段：（1）*发现/广播*，其中附近设备使用短距离无线电（通常为蓝牙/BLE）互相可见，并交换临时端点标识符；（2）*带宽升级协商*，其中对端协商用于批量传输的更高吞吐量的带外通道（例如 Wi-Fi Direct 或临时 Wi-Fi 热点/接入点）；（3）*介绍和同意*，其中发送方传输文件引入元数据，接收方被提示接受传输；以及（4）*负载传输*，其中文件字节通过协商好的高带宽通道传输。[yair2024quickshell, googleQuickShareHelp]

Samsung 的实现扩展了基础 Quick Share，增加了附加功能，包括带有服务器端 URL 预览生成的链接共享，这是 Google 参考实现中不存在的功能。在 Samsung Galaxy S23 Ultra（我们的测试设备）上，Quick Share 作为系统级服务（com.samsung.android.nearby.discovery）运行，具有访问网络 I/O、文件系统操作和用于链接预览的 WebView 渲染的权限。Google 的 Quick Share for Windows 实现处理端点管理，通过一个状态机来管理连接对端的生命周期，该状态机在设备连接和断开时分配和释放端点对象。在涉及多个设备的并发传输期间，如果连接和断开事件同时到达，这些端点对象可能会受到竞争条件的影响，这是我们在 v6 中利用的一个属性（第6.4节 (https://arxiv.org/html/2606.26967#S6.SS4)）。

### 2.3 威胁模型

我们考虑一个位于目标设备无线邻近范围内的攻击者（AWDL/Wi-Fi Direct 范围内，通常 10-30 米）。攻击者拥有一台具有 Wi-Fi 功能的普通笔记本电脑，并且与目标没有事先关系（无配对、无联系人交换、无共享网络）。目标设备已启用 AirDrop 或 Quick Share，处于接受连接的模式（AirDrop 的“所有人”；Quick Share 的默认可见性）。我们专注于*零点击*攻击，即不需要目标设备上的任何用户交互。对于 AirDrop，这意味着在用户接受提示显示之前利用预认证阶段（发现、询问路由）。

## 3 AirDrop 协议逆向工程

我们通过静态和动态分析 macOS 15.7.4 以及最新的 macOS 26.3 和 iOS 18.1/26.3 版本上的 sharingd 和私有 Sharing.framework，对 AirDrop 协议进行了逆向工程。在整个论文中，我们在协议级别描述发现；确切的符号偏移量和按构建版本的反汇编列表作为工件发布。

### 3.1 协议栈概览

表2 (https://arxiv.org/html/2606.26967#S3.T2) 总结了我们识别的七层 AirDrop 协议栈。每一层都引入了不同的序列化格式和潜在的漏洞面。

表 2：AirDrop 协议栈。每一层增加了序列化复杂性和攻击面。

### 3.2 发现和连接建立

AirDrop 设备发现使用 DNS-SD (mDNS) 通过 AWDL，广播服务类型 _airdrop._tcp.local.，带有约 25 个 TXT 键；flags 字段是一个位掩码（例如 0x3FB），编码了 DVZip、流水线上传、混合内容类型、URL 共享、联系人解析和 BLE 支持。发现后，发送方通过 AWDL 打开到接收方 IPv6 链路本地地址端口 8770 的 TLS 连接，使用自签名证书，无需主机名验证，也无需客户端证书。*AWDL 范围内的任何设备都可以建立 TLS 连接并与 HTTP API 交互*，无论接收方的可见性模式如何。

### 3.3 HTTP API 和状态机

AirDrop HTTP API 暴露了七个 POST 端点：
/Discover, /Hello, /Ask, /Upload, /Exchange, /SharedIdentity, /Error

接收端状态机在 SDAirDropConnection 中实现。每个 TLS 连接有三个*请求槽位*——分别用于 Discover、Ask 和 Upload——加上控制标志和一个 dispatch_semaphore_t，该信号量在用户同意提示显示时阻塞请求处理程序。在相应的请求到达之前，槽位为 NULL。
*Discover* 仅在所有三个槽位均为 NULL 时被接受，并返回一个 plist StatusCode 为 100（所有人）、200（联系人匹配）或 401（仅联系人，无匹配）。
*Ask* 也要求所有槽位为 NULL（先清除之前的 Discover 槽位），存储负载，显示同意提示，并在信号量上阻塞直到接受/拒绝或 15 秒超时。
*Upload* 要求 Upload 槽位为 NULL，通常在同一 TLS 连接上成功进行 Ask *之后*进行；发现时的两个 TXT 记录标志被参考——SupportsUPP（位 0xb）允许 Upload *无需*事先的 Ask，SupportsDVZip 启用自适应压缩。Upload 确认