苹果蓝牙保护框架 MagicPairing 被爆出多个 0day 漏洞未修复

让人感到惊讶的是，苹果居然未修复只需检查就能找到的 bug 。近日，来自德国达姆施塔特大学的研究人员检查了 MagicPairing 协议，发现它的三种实现方式 iOS、macOS 和 RTKIT——在它们之间存在十个公开的缺陷，这些缺陷至今尚未得到解决。
苹果蓝牙保护框架：MagicPairing 协议
在了解这项研究成果之前，我们先来了解下 MagicPairing 协议是什么。

MagicPairing 是苹果的一种专有协议，它能够提供无缝的配对功能，例如在用户的 Airpods 和他们所有的苹果设备之间是通过通过苹果的云服务 iCloud 同步键来实现的。MagicPair 协议的最终目标是派生一个蓝牙链路密钥 (LK) ，用于单个设备和 Airpods 之间。为每个连接创建一个新的 LK ，这意味着可以有效地缩短此 LK 的生存期。
当一个新的或重置的一对 Airpods 最初与苹果设备属于 iCloud 帐户，安全简单配对 (SSP) 被使用，所有后续连接到 iCloud 帐户的 Airpod 和设备将使用作为配对机制的 Magicpair 协议。MagicPair 包含多个键和派生函数。它依赖于综合初始化向量 ( SIV ) 模式下的高级加密标准 ( AES ) 进行认证加密。
Magic Pairing 的一般逻辑是可以集成到任何基于的物联网生态系统中，从而增加对整个安全社区的相关性。
尽管 MagicPairing 协议克服了蓝牙设备配对的两个缺点:即可扩展性差和易崩溃安全模型缺陷。（如果永久密钥 Link Layer 或 Long-Term Key 受陷则会崩溃。）
但研究人员使用名为 ToothPicker 的代码执行无线模糊测试和进程内模糊测试后发现了 8 个 MagicPairing 和 2 个 L2CAP 漏洞，它们可导致崩溃、CPU 过载且配对设备关联取消。据外媒报道，这些信息是在 2019 年 10 月 30 日至 2020 年 3 月 13 日期间披露的，目前尚未确定。

“由于 MagicPair 用于配对和加密前，因此它提供了庞大的零点击无线攻击面。我们发现所有的有不同实施都有不同的问题，包括锁定攻击和可导致百分之百 CPU 负载的拒绝服务。我们在开展通用的无线测试和 iOS 进程内模糊测试时发现了这些问题。”
研究人员如是说。
10 个 0day 漏洞一直未修复，苹果未予置评
那么，这些漏洞本身的威胁来自哪里呢？
首先是蓝牙堆栈本身的安全性。
苹果的每个堆栈都是针对单个设备类型的，并且支持一个特性子集。因此，它们支持的协议有重复的实现。虽然这种情况有助于逆转这些协议，但它增加了苹果公司的维护成本。从安全的角度来看，这会导致在这些堆栈中出现双向安全问题。

例如，RTKit 是一个单独的资源约束嵌入设备框架。用于苹果 AirPods 1、2 和 Pro，Siri Remote 2，Apple Pencil 2 和 Smart Keyboard Folio 中，虽然这种分离用来减少功能是有意义的，但 iOS 和 MacOS 也有各自的蓝牙堆栈，由于它们是封闭的，而且只有很少的公开文档。但它在速度上是有限的，不提供覆盖。相比之下，iOS 进程中的模糊处理程序速度更快，不受连接重置的限制，但需要大量的平台专用接口调整。
也就是说，这三个蓝牙堆栈在实际实施中所面临的的攻击和 bug 也会不同。
其次是，零点击无线攻击面大。
Magicpairing 的无线攻击面相当大。首先，它是在配对和加密之前使用的。通过逻辑链路控制和适配协议 ( L2CAP ) 提供的 MagicPairing Providesa 连接，用于蓝牙内部的各种数据传输；第二 , 通过对 IOS、MacOS、RTKit 的实现，进一步扩大了 MagicPair 攻击面。

最后是代码居然有拼写错误问题。
研究人员发现，苹果在 iOS 和 macOS 中的 MagicPairing 实现的日志信息和 macOS Bluetooth 守护进程 bluetoothd 函数名称中存在大量拼写错误。例如，棘轮和 upload 这两个单词在不同的时间被拼成了 diff。但研究人员认为，由于这些误读随堆栈的不同而不同，每个栈可能是由不同的开发人员实现的。虽然拼写错误和实现中的缺陷之间并不直接相关，但这让人认为代码并未仔细审查，开发工作很可能是外包完成的。
但总的来说，这些漏洞虽然存在，也并未修复，但影响不大。苹果也对此问题未予置评。

图文来自 cnBeta，如有侵权请联系删除