還沒升級 iOS11？這個高危漏洞威脅近9成 iPhone 用户！
雷鋒網編者按：Google“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
本文由百度安全實驗室投稿，雷鋒網整理。
雷鋒網原創文章，未經授權禁止轉載。詳情見轉載須知。
資料來源：雷鋒網
作者：百度安全實驗室
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
本文由百度安全實驗室投稿，雷鋒網整理。
雷鋒網原創文章，未經授權禁止轉載。詳情見轉載須知。
資料來源：雷鋒網