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

安全设备/系统

153人已加入

描述

(文章来源:雷锋网)

近日,来自德国达姆施塔特大学的研究人员检查了 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)

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分