欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

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

来源:本站整理 作者:佚名 时间:2018-10-31 TAG: 我要投稿

国外大神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]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载