快捷搜索:

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

(文章滥觞:雷锋网)

近日,来自德国达姆施塔特大年夜学的钻研职员反省了 MagicPairing 协议,发明它的三种实现要领 iOS、macOS 和 RTKIT——在它们之间存在十个公开的缺陷,这些缺陷至今尚未获得办理。在懂得这项钻研成果之前,我们先来懂得下 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 进程内隐隐测试时发清楚明了这些问题。”

苹果的每个客栈都是针对单个设备类型的,并且支持一个特点子集。是以,它们支持的协议有重复的实现。虽然这种环境有助于逆转这些协议,但它增添了苹果公司的掩护资源。从安然的角度来看,这会导致在这些客栈中呈现双向安然问题。

例如,RTKit 是一个零丁的资本约束嵌入设备框架。用于苹果 AirPods 1、2和 Pro,Siri Remote 2,Apple Pencil 2 和 Smart Keyboard Folio 中,虽然这种分离用来削减功能是故意义的,但 iOS 和 MacOS 也有各自的蓝牙客栈,因为它们是封闭的,而且只有很少的公开文档。但它在速率上是有限的,不供给覆盖。比拟之下,iOS 进程中的隐隐处置惩罚法度榜样速率更快,不受连接重置的限定,但必要大年夜量的平台专用接口调剂。

Magicpairing 的无线进击面相昔时夜。首先,它是在配对和加密之前应用的。经由过程逻辑链路节制和适配协议( L2CAP )供给的 MagicPairing Providesa 连接,用于蓝牙内部的各类数据传输;第二, 经由过程对 IOS、MacOS、RTKit 的实现,进一步扩大年夜了 MagicPair 进击面。

钻研职员发明,苹果在 iOS 和 macOS 中的 MagicPairing 实现的日志信息和 macOS Bluetooth 守护进程 bluetoothd 函数名称中存在大年夜量拼写差错。例如,棘轮和 upload 这两个单词在不合的光阴被拼成了 diff。但钻研职员觉得,因为这些误读随客栈的不合而不合,每个栈可能是由不合的开拓职员实现的。虽然拼写差错和实现中的缺陷之间并不直接相关,但这让人觉得代码并未仔细检察,开拓事情很可能是外包完成的。

但总的来说,这些破绽虽然存在,也并未修复,但影响不大年夜。苹果也对此问题未予置评。

(责任编辑:fqj)

您可能还会对下面的文章感兴趣: