讓人感到驚訝的是，蘋果居然未修復只需檢查就能找到的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。但研究人員認為，由於這些誤讀隨堆棧的不同而不同，每個棧可能是由不同的開發人員實現的。雖然拼寫錯誤和實現中的缺陷之間並不直接相關，但這讓人認為代碼並未仔細審查，開發工作很可能是外包完成的。

但總的來說，這些漏洞雖然存在，也並未修復，但影響不大。蘋果也對此問題未予置評。