“毒液”漏洞使全球数以百万计的虚拟机处于网络攻击风险之中，严重威胁各大云服务提供商的数据安全，对此360安全中心发布了深入分析“毒液”漏洞原理的技术报告，并建议广大厂商尽快在源码层面对QEMU实现补丁升级。
漏洞简介
CrowdStrike的Jason Geffner发现开源计算机仿真器QEMU中存在一个和虚拟软盘控制器相关的安全漏洞，代号VENOM，CVE编号为CVE-2015-3456。利用此漏洞攻击者可以在有问题的虚拟机中进行逃逸,并且可以在宿主机中获得代码执行的权限。更多详情见作者博客[1]
背景知识
此漏洞位于qemu的虚拟软驱控制器的模拟代码中。下面介绍几个关于软驱的几个重要的地方。
· 控制寄存器
软驱控制器是由9个寄存器进行控制的，这些寄存器可以通过端口0x3f0-0x3f7进行访问(0x3f6除外[2])。软驱控制器寄存器的定义如下:
漏洞相关的寄存器是DATA_FIFO。
· MSR
同时软驱控制器的MSR标记位表明当时软驱控制器的状态。此次漏洞相关的MSR标记位的定义如下表:
· FIFO命令
命令是向DATA_FIFO写入的一个小于32的单字节的值，每个命令后面都要跟着一些指定长度的参数。命令的ID定义如下所示:
更多见OSDev wiki上的关于软驱控制器的文章
漏洞分析
1.POC触发不了
国外一名安全研究者Marcus Meissner发布了此漏洞poc如下:
我们可以看到,都是向DATA_FIFO端口写入数据，笔者拿到poc先在自己的机器上测试发现poc并不能触发，先不管原因，我们先来分析下qemu对FIFO命令的处理。
2.FIFO命令处理流程
经过分析,我们可以得出其流程如下：首先qemu将FIFO的处理函数以及命令对应的参数个数等信息存放在一个表中,如下所示:
表的每一项都定义了相应命令的一些信息，这里我们将被一项称为一个Handler下同。当qemu接收到FIFO命令之后，通过命令的ID找到这个命令的Handler，然后再根据这个Handler中保存的参数的个数来继续接收参数。并将命令ID和参数放在一个buffer中。在接受完参数后调用相应的处理函数。整个FIFO写操作派发流程都是在函数fdctrl_write_data里。
在处理函数中如果有返回的数据。控制器模拟代码则调用fdctrl_set_fifo这个函数来设置MSR的状态为FD_MSR_DIO,已表示控制器处在可被读状态。注意：设置完以后控制器是不可读的见fdctrl_write_data开始的那个检查。fdctrl_set_fifo代码如下：
如果没有要返回的数据或者返回的数据已经被客户机通过IN指令读取完了，则会调用fdctrl_reset_fifo来重置FIFO。即将FIFO置为可写状态。fdctrl_reset_fifo：
3.为什么不能触发
通过以上流程的分析，我们再来看Marcus Meissner公布的poc的流程：
首先发送一个id为0xa的控制命令。我们可以看到id为0xa的命令为FD_CMD_READ_ID,其对应的处理函数为fdctrl_handle_readid,参数个数为1个。
1. { FD_CMD_READ_ID, 0xbf, “READ ID”, 1, fdctrl_handle_readid },
之后又会写入一个0x42作为READ_ID命令的参数。接下来进入到fdctrl_handle_readid函数内。经过笔者调试fdctrl_handle_readid这个函数启动了一个定时器。在定时器被触发的时候程序调用了fdctrl_set_fifo来生成返回数据。所以接下来的向FIFO写0x42的操作完全没有用，被fdctrl_write_data开始的fdctrl->msr & FD_MSR_DIO这个检查给拦下了。所以这个poc在笔者的机器上并不能触发。
4.新的触发方式
我们先来看下补丁的代码：
可以看到基本上就是补了一些对fdctrl->fifo这个buffer下标的一些防止越界的操作。我们可以肯定这个肯定是个写越界操作了。按照这个思路我们查看了所有命令的处理函数，发现FD_CMD_DRIVE_SPECIFICATION_COMMAND的处理函数有问题。先看下FD_CMD_DRIVE_SPECIFICATION_COMMAND命令的Handler,如下:
1. { FD_CMD_DRIVE_SPECIFICATION_COMMAND, 0xff, “DRIVE SPECIFICATION COMMAND”, 5, fdctrl_handle_drive_specification_command }
命令处理函数为fdctrl_handle_drive_specification_command，参数个数为5。再来看下fdctrl_handle_drive_specification_command函数的实现：
我们找到fdctrl->data_len > 7这个判断是有问题的。我们从fdctrl_write_data这个函数开始，首先传进命令字节FD_CMD_DRIVE_SPECIFICATION_COMMAND，然后依次传进5个参数。按照fdctrl_write_data的流程进入处理函数fdctrl_handle_drive_specification_command时fdctrl->data_len 应该是6，所以我们让fdctrl_handle_drive_specification_command的第一个判断里fdctrl->fifo[fdctrl->data_pos 1]是我们可控的再加上下面的这个fdctrl->data_len > 7这个判断也为否，就绕过了所有调用fdctrl_set_fifo和fdctrl_reset_fifo的地方就是控制器的状态还是可写，而且buffer没有被清空。然后我们就可以无限次向fdctrl->fifo里写入数据，从而超出fdctrl->fifo的边界造成越界写。
fdctrl->fifo的初始化是在fdctrl_realize_common里面:
5.可重现POC
6.重现成功
linux guest:
windows guest:
漏洞总结
这个漏洞为典型的堆溢出漏洞，其表现形式为越界写操作。此漏洞的利用可能还是很大的。另外即使虚拟机没有设置软驱，其漏洞还是无法避免的。鉴于该漏洞属于高危漏洞，建议尽快在源码层面上对QEMU实现补丁升级。
[1]此漏洞原作者博客 http://venom.crowdstrike.com/
[2] IO端口0x3F6是ATA(硬盘)备用状态寄存器，并且不使用任何软盘控制器。
特别提醒：本网内容转载自其他媒体，目的在于传递更多信息，并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益，请及时联系我们，本站将会在24小时内处理完毕。
