還沒升級 iOS11？這個高危漏洞威脅近9成 iPhone 用戶！

雷鋒網編者按：谷歌「Project Zero」團隊近日發現一個嚴重的 Wi-Fi晶片漏洞，目前涉及到的機型包括 iPhone 7、三星S7 edge等各大主流機型，這些手機搭載的博通Wi-Fi晶元存在的後門安全漏洞，非常容易被黑客入侵。考慮到這個漏洞對上億部手機所產生的影響，美國國家標準和技術研究所為補丁嚴重性的評級高達9.8分（滿分10分）。下面這篇文章就對 iOS 系統的 Wi-Fi 晶片漏洞細節進行了詳細剖析，雷鋒網做了不改變原意的整理。

作者：百度安全實驗室

1. 摘要

隨著iOS 11的發布，多個BroadCom WiFi 晶元的高危漏洞被公開[1]。這些漏洞對上億台未來得及更新的iOS設備造成了嚴重的安全威脅。黑客可對同一WiFi網路下的設備發起攻擊，遠程控制受害設備的 WiFi 晶元，甚至進一步攻破 iOS 內核。本文對 iOS 設備 WiFI 晶元相關漏洞進行簡要技術分析，然後根據 iOS設備的系統版本統計出受影響的規模。

截至9月27日，國內92.3%的iOS用戶都受到相關高危漏洞的威脅。我們呼籲用戶儘快升級iOS系統到最新版本，並號召手機廠商採用更有效的防護技術，避免用戶受到已知高危漏洞的威脅。

2. BroadCom WiFi晶元漏洞技術分析

本文著重分析兩個BroadCom WiFi晶元漏洞：CVE-2017-11120和CVE-2017-11121。這兩個漏洞都是WiFi 晶元固件代碼在處理數據幀時缺乏對特定欄位的嚴格校驗。攻擊者可以利用它們製造內存破壞，實現任意代碼執行，獲得對設備的遠程控制。

2.1 漏洞CVE-2017-11120

iOS設備搭載的BroadCom WiFi晶元採用了快速基本服務設置轉換（Fast BSS Transition）和無線資源管理（Radio Resource Management）標準。在接入無線接入點（Access Point，簡稱AP）後，iOS設備會發送相鄰接入點請求（Neighbor Report Request），AP則返回相鄰接入點應答（Neighbor Report Response），包含當前無線區域網內的相鄰AP以及各自的BSSID，Operating Class和Channel Number等信息。在處理Neighbor Report Response數據幀時，BroadCom WiFi晶元將每一種Operating Class和Neighbor Report信息保存在一個456位元組的內存塊中（如圖1所示），並且將這些塊通過指針串接起來。其中，Neighbor Count Array記錄了各個Channel Number的Neighbor數量。Array長度為450位元組，每2個位元組記錄一個Channel Number，所以最大可記錄的Channel Number為224（0xE0）。

圖1：BroadCom WiFi晶元記錄Neighbor Report Response信息的內存塊結構 [2]

圖2：BroadCom WiFi晶元處理Neighbor Report Response信息的函數 [2]

如圖 2 所示，WiFi 晶元固件里位於地址 0xAC0A8 的函數（簡稱function_AC0A8，下同）首先在串聯的內存塊中查找Operating Class對應的條目，如果沒有找到，則會動態創建一個條目 ，然後從數據幀中讀出Channel Number作為數組索引，定位到 Neighbor Count Array 中元素，將其值加一。此過程並沒有對Channel Number做出校驗，當偽造的數據幀中 Channel Number大於0xE0（如0xFF）時，上述過程將會造成內存越界寫。攻擊者可以通過內存越界寫改變關鍵指針數據或者控制流元素，一步步接管代碼執行。值得一提的是，BroadCom WiFi 晶元里沒有 ASLR、DEP 等防護，攻擊者可以很容易做代碼改寫，注入任意代碼執行。

此漏洞影響 iOS 11.0 以前的設備。目前此漏洞的利用代碼已公開[2]，攻擊者能直接復用這一利用代碼攻擊漏洞設備，在WiFi晶元中插入後門，並在用戶無感知的情況下實現對設備的遠程控制。

2.2 漏洞CVE-2017-11121

根據 Fast BSS Transition 標準，當設備在無線網路環境下進行快速漫遊（fast roaming）時，會觸發校驗和重關聯（reassociation）操作。Reassociation操作會對組臨時秘鑰（Group Temporal Key，簡稱GTK）進行解密和安裝。這兩個過程中存在多處 memcpy 調用，調用前都缺少對 copy 長度的校驗，可能導致內存破壞。

圖3：BroadCom WiFi晶元重關聯操作時GTK解密和安裝的相關函數 [3]

如圖3所示，reassociation 由 function_8462C 函數負責，它調用 function_6D8對GTK 解密，然後會繼續調用 function_C9C14對GTK 進行安裝。相關代碼片段如下：

上述處理過程中，有兩處 memcpy 調用存在問題：

1）GTK解密函數 function_6D8 中，當構造的畸形數據幀中 gtk_subelem[1]為11時，函數參數input_length為0。在第二處調用 memcpy 時，input_length-8為0xfffffff8，這將導致大量數據被 copy，破壞 stack上的數據；

2）GTK安裝函數 function_C9C14，參數 gtk_len 取值為 gtk_subelem[4]。攻擊者可以構造畸形數據幀，使 gtk_subelem[4]大於164，函數中 memcpy 調用前沒有檢查 gtk_len 取值，可能導致堆溢出。

攻擊者同樣可以攻擊此漏洞造成內存破壞，實現遠程任意代碼執行。此漏洞影響系統版本在11.0以前的iOS設備。

3. 通過WiFi晶元漏洞可進一步攻擊iOS內核

攻擊者可將WiFi晶元漏洞作為跳板，進一步攻擊 iOS 內核。iOS 設備進行 WiFi 通信時，內核的 WiFi 驅動會向 WiFi 晶元發送 ioctl 請求。如果WiFi晶元被攻擊者控制，攻擊者能夠篡改 ioctl 返回的結果數據，觸發內核WiFi驅動中結果處理函數的漏洞，從而實現對 iOS 內核的攻擊。

表1: 當攻擊者控制WiFi晶元後，可用於攻擊iOS內核驅動的漏洞

表1中列舉了可由WiFi晶元作為跳板攻擊內核的漏洞。漏洞原理簡要說明如下：

 CVE-2017-7103：驅動AppleBCMWLANBusInterfacePCIe中的函數completeFirmwareTimestampMsg，在Firmware Timestamp消息完成後會被回調。函數內部將Timestamp消息封裝為mbuf，交由processFirmwareTimeSyncMessage處理，mbuf pkthdr_len設置為消息中timestamp_length欄位的值。processFirmwareTimeSyncMessage函數內部存在一處memmove調用，長度參數為pkthdr_len。程序沒有對pkthdr_len進行檢查，構造過大的pkthdr_len會使memmove調用產生內存溢出。

 CVE-2017-7105：驅動AppleBCMWLANCore中的函數assembleBGScanResults，在處理WLC_GET_VAR ioctl返回的結果時，會調用IOMalloc分配一塊堆內存，內存分配長度根據返回結果中的欄位計算得出。代碼中缺少對分配長度的溢出校驗，在WiFi晶元被控制情況下，攻擊者可通過篡改ioctl返回數據，使IOMalloc分配長度在計算時產生整型溢出，進而導致過小的內存分配，後續對分配內存的copy操作可能引起堆溢出。

 CVE-2017-7108：驅動AppleBCMWLANCore中的updateRateSetAsyncCallback函數，在處理WLC_GET_CURR_RATESET ioctl請求結果時，首先將0x14位元組的結果數據中讀到棧中buffer。rate數目由buffer中前4位元組獲得，接著函數從buffer+4處循環讀出rate數據。由於在循環操作前缺少對rate數目的校驗，攻擊者可以篡改ioctl返回的rate結果，將rate數目欄位改為過大的值，實現對buffer數據的越界讀，造成棧上數據信息泄露。

 CVE-2017-7110：設備向WiFi晶元發送獲得所有Vendor IE列表信息的ioctl請求，返回結果交由驅動AppleBCMWLANCore中setVendorIE函數處理。setVendorIE內部調用obvcopy時，length參數根據ioctl返回結果中欄位的計算得出。然而程序中缺乏對length值的校驗，在WiFi晶元受控下，攻擊者可以構造畸形請求結果，使得obvcopy的length過大，導致堆溢出。

 CVE-2017-7112：驅動AppleBCMWLANCore中handleTraceEvent函數，在處理WLC_E_TRACE消息時，缺少對消息頭中len欄位的檢查。而後根據len計算得到的數組索引，進而改寫數組內容時，可能對數組以外的內存寫入NULL byte。

4. 絕大多數iOS用戶受到WiFi高危漏洞威脅

截至2017年9月27日，通過對國內上億台iOS設備的系統版本進行的統計，排除虛假設備干擾結果後，詳細系統版本比例分布如圖4所示。從左半部分開始，逆時針方向按新舊版本次序依次為最新的iOS 11.x到iOS 7.x。其中，最新的iOS 11.x設備佔比為7.7%，iOS 10.3.3系統佔比50.8%，此版本之外的iOS 10.x版本（10.0.0至10.3.2）佔比23.8%。早期的iOS 9.x設備佔比11.2%，iOS 8.x 佔比 5.8%，更早期的iOS 7佔比 0.7%。

從圖中可以看到，目前國內升級到最新的iOS 11.x系統的設備僅佔7.7%，有近半的iOS設備系統版本為10.3.3。其餘設備停留在10.3.2到更早的7.x等不同的版本。這些舊版iOS系統的設備（高達92.3%）面臨著文中列舉的WiFi晶元高危漏洞帶來的安全威脅。

圖4：國內iOS設備系統版本分布（2017年9月27日）

此外，我們統計了從2017年9月11日到2017年9月27日（iOS 11的升級推出於9月19日）iOS各個系統版本的升級情況。結果如圖5所示。可以看到，從9月19日開始推送iOS 11.0升級至9月27日期間，iOS 11.x用戶佔比緩慢遞增至7.7%，升級主要來源於iOS 10.3.3。整個統計期間iOS 7.x至10.x的用戶佔比基本不變，也就是說，仍然有近41.5%的用戶選擇停留在iOS 10.3.2及以下系統不升級。

圖5：國內iOS設備系統升級趨勢（2017年9月11日-2017年9月27日）

5. 結語

本文分析了近期曝出的iOS設備WiFi晶元高危漏洞以及影響範圍。文中提及的漏洞雖然已在iOS 11得到修復，但通過實際統計發現，絕大多數用戶由於各種原因沒有升級上來，仍面臨嚴重的安全威脅。雷鋒網建議用戶及時升級系統到最新版本，避免受到高危漏洞影響。同時，我們也呼籲手機以及硬體廠商採取更積極的防護技術，避免用戶受到已知的高危漏洞威脅。

參考文獻

[1].https://support.apple.com/en-us/HT208112

[2].https://bugs.chromium.org/p/project-zero/issues/detail?id=1289

[3].https://bugs.chromium.org/p/project-zero/issues/detail?id=1291

[4].https://bugs.chromium.org/p/project-zero/issues/detail?id=1302

[5].https://bugs.chromium.org/p/project-zero/issues/detail?id=1305

[6].https://bugs.chromium.org/p/project-zero/issues/detail?id=1312&can=1&q=CVE-2017-7108

[7].https://bugs.chromium.org/p/project-zero/issues/detail?id=1313&can=1&q=CVE-2017-7110

[8].https://bugs.chromium.org/p/project-zero/issues/detail?id=1314&can=1&q=owner%3Alaginimaineb%40google.com

本文由百度安全實驗室投稿，雷鋒網整理。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！