缓冲区溢出漏洞（CVE-2018-4407）可导致内核崩溃，苹果多款操作系统均受影响

前言

国外大神Kevin Backhouse刚刚放出了一篇博文，对苹果操作系统内核中发现的堆缓冲区溢出漏洞（CVE-2018-4407）进行了一番解构。

该漏洞使得攻击者只要接入同一Wi-Fi网络，即可向其他毫不知情的用户发送恶意数据包来触发任何Mac或iOS设备的崩溃和重启。由于该漏洞存在于系统网络核心代码，因此任何反病毒软件均无法防御。

运行以下操作系统的设备易受攻击：

Apple iOS 11及更早版本：所有设备（升级到iOS 12的部分设备）

Apple macOS High Sierra（受影响的最高版本为10.13.6）：所有设备（通过 安全更新2018-001 修复）

Apple macOS Sierra（受影响的最高版本为10.12.6）：所有设备（通过 安全更新2018-005中 修复）

Apple OS X El Capitan及更早版本：所有设备

好在Kevin在发现这个漏洞后马上就向苹果报告了，苹果在10月30日推出的iOS 12.1更新包中彻底修复了这个漏洞。

概述

该漏洞是苹果 XNU 操作系统内核中网络代码的堆缓冲区溢出问题导致的，iOS和macOS都使用XNU，因此iPhone、iPad和的MacBook均受到影响。想要触发该漏洞，攻击者只需要连接到与目标设备相同的网络，发送恶意IP数据到目标设备的IP地址即可，无需诱骗用户进行任何交互操作。

举个例子：

用户在咖啡馆使用免费Wi-Fi时，攻击者可以加入相同的无线网络并向用户的设备发送恶意数据包就可以让设备崩溃和重启。（攻击者只要使用 NMAP 工具就能很方便地获得设备IP地址。）

由于该漏洞的成因来源于系统的核心代码，反病毒软件也无法防御。 Kevin在运行 McAfee ® Endpoint Security for Mac 的Mac上成功测试了该漏洞。这和用户在设备上运行的软件也没有关系，即使没有打开任何端口，恶意数据包仍会触发漏洞。

进一步推测的话，由于攻击者可以控制堆缓冲区溢出的大小和内容，因此他们可能利用此漏洞在目标设备执行远程代码。

缓解措施

在未升级到最新版本操作系统的设备上，目前已知的缓解措施只有以下两个：

在macOS防火墙中启用 隐藏模式 可防止攻击。这个系统设置默认情况下不启用，需要用户手动开启。iOS设备不支持隐藏模式。

不接入公共无线网络。触发该漏洞的唯一必要条件是处于同一Wi-Fi网络，该漏洞不支持通过互联网发送恶意数据包而触发，Kevin测试过了。

漏洞分析

该漏洞来源于代码中的缓冲区溢出（ bsd/netinet/ip_icmp.c:339 ）：

m_copydata(n, 0, icmplen, (caddr_t)&icp->icmp_ip);

函数 icmp_error 使用该代码，目的是“生成包含错误信息的数据包以响应发生错误的IP”。它使用 ICMP协议 发送错误消息，引发错误的数据报头包含在ICMP消息中，上述第339行代码调用m_copydata的目的是复制错误数据包的报头到ICMP消息。

问题在于报头对于目标缓冲区来说可能太大了。目标缓冲区是mbuf，mbuf是一种数据类型，用于存储传入和传出的网络数据包。在此代码中，n是一个传入的数据包（包含不受信任的数据），而m是传出的ICMP数据包。我们可以看到，icp是指向m的指针。m在 第294行或第296行 进行部署：

if (MHLEN > (sizeof(struct ip) + ICMP_MINLEN + icmplen))
  m = m_gethdr(M_DONTWAIT, MT_HEADER);  /* MAC-OK */
else
  m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR);

往下看 第314行 ，mtod用于获取m的数据指针：

icp = mtod(m, struct icmp *);

mtod仅仅是个宏，因此这行代码不会检查mbuf是否足以容纳icmp结构。此外，数据没有复制到icp，而是复制到&icp->icmp_ip，存在+8字节偏移。

由于没有必要的工具，Kevin无法在调试器中单步执行XNU内核，因此对于mbuf的分配大小没有确切的数值。基于源代码提供的信息，这里推测m_gethdr创建一个mbuf可以容纳88个字节，m_getcl无法确定。但是根据实验结果，触发该缓冲区溢出漏洞时满足icmplen >= 84的条件即可。

漏洞的发现过程

使用QL查找漏洞

Kevin是在分析 数据包管理程序 缓冲区溢出漏洞时发现的该漏洞。漏洞是由对于mbuf_copydata的调用（包含用户控制的大小参数）引起的，因此只要写一个简单的查询脚本即可发现类似错误：

**
 * @name mbuf copydata with tainted size
 * @description Calling m_copydata with an untrusted size argument
 *              could cause a buffer overflow.
 * @kind path-problem
 * @problem.severity warning
 * @id apple-xnu/cpp/mbuf-copydata-with-tainted-size
 */

import cpp
import semmle.code.cpp.dataflow.TaintTracking
import DataFlow::PathGraph

class Config extends TaintTracking::Configuration {
  Config() { this = "tcphdr_flow" }

  override predicate isSource(DataFlow::Node source) {
    source.asExpr().(FunctionCall).getTarget().getName() = "m_mtod"
  }

  override predicate isSink(DataFlow::Node sink) {
    exists (FunctionCall call
    | call.getArgument(2) = sink.asExpr() and
      call.getTarget().getName().matches("%copydata"))
  }
}

from Config cfg, DataFlow::PathNode source, DataFlow::PathNode sink
where cfg.hasFlowPath(source, sink)
select sink, source, sink, "m_copydata with tainted size."

这是一个很简单的问题跟踪方法，它的查找范围涵盖m_mtod到CopyData函数的参数大小的数据流。m_mtod函数返回一个mbuf的数据指针，它很可能会返回不受信任的数据，所以mtod宏指令是根源所在。而m_mtod这只是XNU内核中不受信任数据的众多来源之一。

使用上述方法进行查询后返回9个结果，其中第一个是漏洞icmp_error，其他8个结果误报的可能性较大。

在XNU上尝试QL

与大多数其他开源项目不同，XNU无法通过查询LGTM获得有用的信息。因为LGTM使用 Linux 流程构建项目，但XNU只能在苹果电脑上构建。即使在苹果电脑上，构建XNU也非常不容易。Kevin参考了Jeremy Andrus的 博客文章 ，才得以为三个最新发布的XNU版本手动构建了快照（下载快照 10.13.4 ， 10.13.5 ， 10.13.6 ）。由于苹果尚未发布10.14（Mojave/ iOS的12）的源代码，因此无法创建QL快照来运行针对性的检查。要在这些QL快照上运行查询脚本，需要下载 QL for Eclipse ，点击 此处 获得有关如何使用QL for Eclipse的说明。

漏洞验证视频

为了让苹果用户有充分的时间升级，Kevin不会立即放出PoC代码，而是制作了一个简短的视频来验证漏洞。

*参考来源： lgtm ，Freddy编译整理，转载请注明来自 FreeBuf.COM。