360MarvelTeam虚拟化漏洞第一弹 – CVE-2015-6815 漏洞分析

前言

云计算业务目前已经触及到多个行业,无论是云存储,云音乐等生活中随处可见的业务,就连银行金融,支付信息等服务也都和云紧密相关。作为云服务的基础,虚拟化系统扮演着非常重要的角色,因为在云生态中主机的硬件多是由虚拟化系统模拟出来的。可以说,没有虚拟化系统的稳定运行,云业务的健康发展是不可能实现的。

360虚拟化安全团队(MarvelTeam)近日发现了多个虚拟化软件安全漏洞,使用kvm和xen作为虚拟化平台的公司业务都将会受这批漏洞影响。该漏洞一旦被攻击者恶意利用,可以造成三种类型的安全风险:;虚拟机宕机,影响业务;系统资源被强制占用,宿主机及所有虚拟机拒绝服务;虚拟机逃逸,攻击者在宿主机中执行任意代码。

360虚拟化安全团队(MarvelTeam)将陆续公开一系列针对虚拟化软件高危0day漏洞的分析文章,揭开宿主机攻击技术的神秘面纱。在9月29日的在ISC 2015大会上,该团队安全研究员唐青昊,将进行关于《云虚拟化系统的漏洞挖掘技术》议题的演讲,在该议题中将分享漏洞挖掘的核心技术。

本文为该系列的第一篇文章,将详细分析CVE-2015-6815漏洞的相关知识。

 

一. 关于QEMU和KVM

QEMU是一款处理器模拟软件,可以提供用户模式模拟和系统模式模拟。当处于用户模式模拟状态时,将使用动态翻译技术,允许一个cpu构建的进程在另一个cpu上执行。系统模式模拟状态下,允许对整个pc系统的处理器和所使用到的相关外围设备进行模拟。qemu提供的仿真外设包括硬件Video Graphics Array (VGA) 仿真器、PS/2 鼠标和键盘、集成开发环境(IDE)硬盘和 CD-ROM 接口,以及软盘仿真。也包括对E2000 Peripheral Controller Interconnect (PCI) 网络适配器、串行端口、大量的声卡和 PCI Universal Host Controller Interface (UHCI) Universal Serial Bus (USB) 控制器(带虚拟 USB 集线器)的仿真。除了仿真标准 PC 或 ISA PC(不带 PCI 总线)外,QEMU 还可以仿真其他非 PC 硬件,如 ARM Versatile 基线板(使用 926E)和 Malta million instructions per second (MIPS) 板。对于各种其他平台,包括 Power Macintosh G3 (Blue & White) 和 Sun-4u 平台,都能正常工作。

1

图1.qemu可进行模拟的外围设备

 

KVM是一种依赖硬件虚拟化技术(Intel VT或者AMD V)的裸机虚拟化程序,它使用 Linux 内核作为它的虚拟机管理程序。对 KVM 虚拟化的支持自 2.6.20 版开始已成为主流 Linux 内核的默认部分。KVM支持的操作系统非常广泛,包括Linux、BSD、Solaris、Windows、Haiku、ReactOS 和 AROS Research Operating System。

在 KVM 架构中,虚拟机实现为常规的 Linux 进程,由标准 Linux 调度程序进行调度。事实上,每个虚拟 CPU 显示为一个常规的 Linux 进程。这使 KVM 能够享受 Linux 内核的所有功能。设备模拟由提供了修改过的 qemu 版本来完成。

 

二. QEMU网卡设备简介

QEMU支持多种网卡设备,可以通过如下的命令去列举所支持的网卡设备类型,一共有8种,基本可以满足大多数操作系统的需求。

2

图2.qemu支持的虚拟网卡设备

 

此次漏洞出现在e1000网卡设备中,该网卡的基本功能等同于Intel rc82540EM硬件网卡,支持TSO技术,网络数据传输效率极高。

 

三. 漏洞分析

CVE-2015-6815是qemu软件的虚拟网卡设备存在的一处逻辑漏洞,攻击者可通过构造恶意的数据流触发该漏洞。我们分析网卡在处理恶意数据流时执行的逻辑:

a)网卡驱动向网卡设备发送指令,通知网卡设备执行数据发送操作;

b)set_tctl(E1000State *s, int index, uint32_t val) ;当网卡设备判断已经设置相关寄存器,即开始进行发包操作,进入set_tctl函数中进行相关处理,函数原型如下:

c)start_xmit(E1000State *s) ;start_xmit函数首先检查(s->reg[TCTL]&E1000_TCTL_EN),若等于0,表示没开启发送功能,将直接退出。否则判断是否存在有效的描述符,有的话则依次取出描述符交给process_tx_desc处理。

d)存在漏洞的函数源码如下:

static void
process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
{
    PCIDevice *d = PCI_DEVICE(s);
    uint32_t txd_lower = le32_to_cpu(dp->lower.data);
    uint32_t dtype = txd_lower & (E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D);
    unsigned int split_size = txd_lower & 0xffff, bytes, sz, op;
    unsigned int msh = 0xfffff;
    uint64_t addr;
    struct e1000_context_desc *xp = (struct e1000_context_desc *)dp;
    struct e1000_tx *tp = &s->tx;

    s->mit_ide |= (txd_lower & E1000_TXD_CMD_IDE);
    if (dtype == E1000_TXD_CMD_DEXT) {	// context descriptor
        op = le32_to_cpu(xp->cmd_and_length);
        tp->ipcss = xp->lower_setup.ip_fields.ipcss;
        tp->ipcso = xp->lower_setup.ip_fields.ipcso;
        tp->ipcse = le16_to_cpu(xp->lower_setup.ip_fields.ipcse);
        tp->tucss = xp->upper_setup.tcp_fields.tucss;
        tp->tucso = xp->upper_setup.tcp_fields.tucso;
        tp->tucse = le16_to_cpu(xp->upper_setup.tcp_fields.tucse);
        tp->paylen = op & 0xfffff;
        tp->hdr_len = xp->tcp_seg_setup.fields.hdr_len;
        tp->mss = le16_to_cpu(xp->tcp_seg_setup.fields.mss);
        tp->ip = (op & E1000_TXD_CMD_IP) ? 1 : 0;
        tp->tcp = (op & E1000_TXD_CMD_TCP) ? 1 : 0;
        tp->tse = (op & E1000_TXD_CMD_TSE) ? 1 : 0;
        tp->tso_frames = 0;
        if (tp->tucso == 0) {	// this is probably wrong
            DBGOUT(TXSUM, "TCP/UDP: cso 0!\n");
            tp->tucso = tp->tucss + (tp->tcp ? 16 : 6);
        }
        return;
    } else if (dtype == (E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D)) {
        // data descriptor
        if (tp->size == 0) {
            tp->sum_needed = le32_to_cpu(dp->upper.data) >> 8;
        }
        tp->cptse = ( txd_lower & E1000_TXD_CMD_TSE ) ? 1 : 0;
    } else {
        // legacy descriptor
        tp->cptse = 0;
    }

    if (vlan_enabled(s) && is_vlan_txd(txd_lower) &&
        (tp->cptse || txd_lower & E1000_TXD_CMD_EOP)) {
        tp->vlan_needed = 1;
        stw_be_p(tp->vlan_header,
                      le16_to_cpu(s->mac_reg[VET]));
        stw_be_p(tp->vlan_header + 2,
                      le16_to_cpu(dp->upper.fields.special));
    }
        
    addr = le64_to_cpu(dp->buffer_addr);
    if (tp->tse && tp->cptse) {
        msh = tp->hdr_len + tp->mss;
        do {
            bytes = split_size;
            if (tp->size + bytes > msh)
                bytes = msh - tp->size;

            bytes = MIN(sizeof(tp->data) - tp->size, bytes);
            pci_dma_read(d, addr, tp->data + tp->size, bytes);
            sz = tp->size + bytes;
            if (sz >= tp->hdr_len && tp->size < tp->hdr_len) {
                memmove(tp->header, tp->data, tp->hdr_len);
            }
            tp->size = sz;
            addr += bytes;
            if (sz == msh) {
                xmit_seg(s);
                memmove(tp->data, tp->header, tp->hdr_len);
                tp->size = tp->hdr_len;
            }
        } while (split_size -= bytes);
    } else if (!tp->tse && tp->cptse) {
        // context descriptor TSE is not set, while data descriptor TSE is set
        DBGOUT(TXERR, "TCP segmentation error\n");
    } else {
        split_size = MIN(sizeof(tp->data) - tp->size, split_size);
        pci_dma_read(d, addr, tp->data + tp->size, split_size);
        tp->size += split_size;
    }

    if (!(txd_lower & E1000_TXD_CMD_EOP))
        return;
    if (!(tp->tse && tp->cptse && tp->size < tp->hdr_len)) {
        xmit_seg(s);
    }
    tp->tso_frames = 0;
    tp->sum_needed = 0;
    tp->vlan_needed = 0;
    tp->size = 0;
    tp->cptse = 0;
}

 

根据注释,可以清晰地看到,该函数的主要目的是按照3种类型来处理网卡数据描述符表中的单个描述符,分别是context descriptor,data descriptor,legacy descriptor,这三种类型代表了不同的数据内容:描述信息,数据,遗留信息,网卡通过判断处于何种类型,设置s->tx的状态位,然后根据tp->tse 和 tp->cptst来确定是否要调用xmit_seg函数以及怎样填充buf,由于函数对驱动传进来描述符的内容没有检测,可设置成任意值。xmit_seg函数根据s->tx中各字段的信息来填充s->data,最后调用qemu_send_packet函数发送s->data,qemu_send_packet(nc, buf, size)。

在该函数的执行过程中,攻击者通过恶意的数据流,可以控制该函数中的tp->hdr_len和tp->mss数据的值,而 msh = tp->hdr_len + tp->mss。在进入do…while 循环之后,tp->size值为0,而bytes和msh的值可以控制,通过迫使代码逻辑进入第一个if循环,可将bytes设置为msh的值,即bytes也可以被控制。之后,bytes可以一直保持值不变,直至进入while的条件判断语句,此时如果bytes为0,则do…while进入死循环的逻辑。

四. 漏洞危害

攻击者利用该漏洞可以导致虚拟机拒绝服务,并且保持对cpu的高占用率,继而会影响宿主机以及其他虚拟机的正常执行。

我们在测试环境中对该漏洞进行测试,触发前后的截图如下。可以看到,在漏洞触发后宿主机的空闲cpu百分比一直锁定为为0%。

5

图3.触发漏洞前

6

图4.触发漏洞后

 

五. 漏洞修补方案

360虚拟化安全团队(MarvelTeam)在发现了该漏洞之后,第一时间通知QEMU软件官方团队进行修复。官方在20天的紧张修复之后,在9月5日完成对该漏洞的修复补丁。详细信息见https://access.redhat.com/security/cve/CVE-2015-6815,该网页也包含了360虚拟化安全团队的致谢。

官方对该漏洞的修补方法如下:

7

图5.官方提供的漏洞补丁

在该补丁中,开发人员加入了对漏洞关键数据 – bytes数值的判断,如为0,则退出循环,完美修复漏洞。

建议所有使用qemu的厂商应尽快采用该补丁,防止攻击者对在虚拟机中利用CVE-2015-6815漏洞。

关于 “360MarvelTeam虚拟化漏洞第一弹 – CVE-2015-6815 漏洞分析” 的一个意见

评论关闭。