0
| 本文作者： 郭佳 | 2017-10-01 16:21 |
雷锋网编者按：谷歌“Project Zero”团队近日发现一个严重的 Wi-Fi晶片漏洞，目前涉及到的机型包括 iPhone 7、三星S7 edge等各大主流机型，这些手机搭载的博通Wi-Fi芯片存在的后门安全漏洞，非常容易被黑客入侵。考虑到这个漏洞对上亿部手机所产生的影响，美国国家标准和技术研究所为补丁严重性的评级高达9.8分（满分10分）。下面这篇文章就对 iOS 系统的 Wi-Fi 晶片漏洞细节进行了详细剖析，雷锋网做了不改变原意的整理。
作者：百度安全实验室
随着iOS 11的发布，多个BroadCom WiFi 芯片的高危漏洞被公开[1]。这些漏洞对上亿台未来得及更新的iOS设备造成了严重的安全威胁。黑客可对同一WiFi网络下的设备发起攻击，远程控制受害设备的 WiFi 芯片，甚至进一步攻破 iOS 内核。本文对 iOS 设备 WiFI 芯片相关漏洞进行简要技术分析，然后根据 iOS设备的系统版本统计出受影响的规模。
截至9月27日，国内92.3%的iOS用户都受到相关高危漏洞的威胁。我们呼吁用户尽快升级iOS系统到最新版本，并号召手机厂商采用更有效的防护技术，避免用户受到已知高危漏洞的威胁。
本文着重分析两个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设备。
攻击者可将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。
截至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日）
本文分析了近期曝出的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
本文由百度安全实验室投稿，雷锋网整理。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
