<mark id="oztn4"></mark>
0
讓人感到驚訝的是，蘋果居然未修復只需檢查就能找到的 bug 。
近日，來自德國達姆施塔特大學的研究人員檢查了 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 進程中的模糊處理程序速度更快，不受連接重置的限制，但需要大量的平臺專用接口調整。
也就是說，這三個藍牙堆棧在實際實施中所面臨的的攻擊和 bug 也會不同。
其次是，零點擊無線攻擊面大。
Magicpairing 的無線攻擊面相當大。首先，它是在配對和加密之前使用的。通過邏輯鏈路控制和適配協議( L2CAP )提供的 MagicPairing Providesa 連接，用于藍牙內部的各種數據傳輸；第二, 通過對 IOS、MacOS、RTKit 的實現，進一步擴大了 MagicPair 攻擊面。
最后是代碼居然有拼寫錯誤問題。
研究人員發現，蘋果在 iOS 和 macOS 中的 MagicPairing 實現的日志信息和 macOS Bluetooth 守護進程 bluetoothd 函數名稱中存在大量拼寫錯誤。例如，棘輪和 upload 這兩個單詞在不同的時間被拼成了 diff。但研究人員認為，由于這些誤讀隨堆棧的不同而不同，每個棧可能是由不同的開發人員實現的。雖然拼寫錯誤和實現中的缺陷之間并不直接相關，但這讓人認為代碼并未仔細審查，開發工作很可能是外包完成的。
但總的來說，這些漏洞雖然存在，也并未修復，但影響不大。蘋果也對此問題未予置評。
雷鋒網雷鋒網雷鋒網
參考來源：
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
