缓冲区溢出漏洞(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内核中不受相信数据的浩繁滥觞之一。

[1] [2]下一页

应用上述措施进行查询后返回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的阐明。

上一页[1] [2]

赞(0) 打赏
分享到: 更多 (0)
免责申明:本站所有资料均来自于网络,版权归原创者所有!本站不提供任何保证,不保证真实性,并不承担任何法律责任

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

阿里云优惠网 更专业 更优惠

阿里云优惠券阿里云大礼包