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

网络采集2018-11-07 11:33:53 342
版权声明:本站部分内容来自网络转载,如有版权问题,请联系我们。

前言

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

微信截图_20181031152439.png

该漏洞使得攻击者只要接入同一的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设备和Mac系统都使用XNU,因此在iPhone,iPad和的的MacBook均受到影响。想要触发该漏洞,攻击者只需要连接到与目标设备相同的网络,发送恶意IP数据到目标设备的IP地址即可,无需诱骗用户进行任何交互操作。

ICMP

举个例子:

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

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

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

缓解措施

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

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

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

漏洞分析

该漏洞来源于代码中的缓冲区溢出(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是一个传入的数据包(包含不受信任的数据),而米是传出的ICMP数据包我们可以看到,ICP是指向米的指针的.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用于获取米的数据指针:

icp = mtod(m, struct icmp *);

MTOD仅仅是个宏,因此这行代码不会检查的mbuf是否足以容纳ICMP结构。此外,数据没有复制到ICP,而是复制到与ICP-> icmp_ip,存在8字节偏移。

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

漏洞的发现过程

使用QL查找漏洞

凯文在的英文分析数据包管理程序缓冲区溢出漏洞时发现的该漏洞漏洞的英文由对于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 cppimport semmle.code.cpp.dataflow.TaintTrackingimport DataFlow::PathGraphclass 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 sinkwhere 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参考了杰里米安德鲁斯的博客文章,才得以为三个最新发布的XNU版本手动构建了快照(下载快照10.13.410.13.510.13.6)。由于苹果尚未发布10.14(莫哈韦/ iOS的的12)的源代码,因此无法创建QL快照来运行针对性的检查。要在这些QL快照上运行查询脚本,需要下载QL for Eclipse,点击此处获得有关如何使用QL for Eclipse的说明。


本站一切资源来源于网络采集,仅用作交流学习,请勿用作商业或违法行为!如造成任何后果,本站概不负责!如有任何问题或者意见,请联系网站管理员:jzroot#gmail.com