virtualbox_e1000_0day

Why

Mi piace VirtualBox e non c'entra nulla con il motivo per cui pubblico una vulnerabilità 0day. La ragione è il mio disaccordo con lo stato attuale dell'infosec, in particolare della ricerca sulla sicurezza e del bug bounty:

1. Aspettare sei mesi finché una vulnerabilità non viene patchata è considerato accettabile.
2. Nel campo del bug bounty queste cose sono considerate accettabili:
   1. Aspettare più di un mese prima che una vulnerabilità inviata venga verificata e venga presa una decisione sull'acquisto o meno.
   2. Cambiare decisione al volo. Oggi hai capito che il programma di bug bounty comprerà bug in un software, una settimana dopo arrivi con bug ed exploit e ricevi "non interessati".
   3. Non avere una lista precisa del software per cui un bug bounty è interessato a comprare bug. Comodo per i bug bounty, scomodo per i ricercatori.
   4. Non avere limiti minimi e massimi precisi dei prezzi delle vulnerabilità. Ci sono molte cose che influenzano un prezzo, ma i ricercatori devono sapere su cosa vale la pena lavorare e cosa no.
3. Delirio di onnipotenza e marketing spazzatura: dare un nome alle vulnerabilità e creare siti web per loro; fare mille conferenze in un anno; esagerare l'importanza del proprio lavoro come ricercatore di sicurezza; considerarsi "salvatore del mondo". Scendi dal piedistallo, Vostra Altezza.

Sono esausto dei primi due, quindi la mia mossa è la divulgazione completa. Infosec, per favore, fai un passo avanti.

General Information

Vulnerable software: VirtualBox 5.2.20 and prior versions. Host OS: any, the bug is in a shared code base. Guest OS: any. VM configuration: default (the only requirement is that a network card is Intel PRO/1000 MT Desktop (82540EM) and a mode is NAT).

How to protect yourself

Until the patched VirtualBox build is out you can change the network card of your virtual machines to PCnet (either of two) or to Paravirtualized Network. If you can't, change the mode from NAT to another one. The former way is more secure.

Introduction

A default VirtualBox virtual network device is Intel PRO/1000 MT Desktop (82540EM) and the default network mode is NAT. We will refer to it as E1000.

The E1000 has a vulnerability allowing an attacker with root/administrator privileges in a guest to escape to a host ring3. Then the attacker can use existing techniques to escalate privileges to ring 0 via /dev/vboxdrv.

Vulnerability Details

E1000 101

Per inviare pacchetti di rete, un guest fa ciò che fa un normale PC: configura una scheda di rete e le fornisce i pacchetti. I pacchetti sono composti da frame del livello data link e altre intestazioni di livello superiore. I pacchetti forniti all'adattatore sono avvolti in descrittori Tx (Tx sta per transmit). Il descrittore Tx è una struttura dati descritta nel datasheet 82540EM (317453006EN.PDF, Revision 4.0). Memorizza metainformazioni come dimensione del pacchetto, tag VLAN, flag di abilitazione della segmentazione TCP/IP e così via.

Il datasheet 82540EM prevede tre tipi di descrittori Tx: legacy, context, data. Credo che legacy sia deprecato. Gli altri due sono usati insieme. L'unica cosa che ci interessa è che i descrittori context impostano la dimensione massima del pacchetto e attivano la segmentazione TCP/IP, e che i descrittori data contengono gli indirizzi fisici dei pacchetti di rete e le loro dimensioni. La dimensione del pacchetto del descrittore data deve essere inferiore alla dimensione massima del pacchetto del descrittore context. Di solito i descrittori context vengono forniti alla scheda di rete prima dei descrittori data.

Per fornire i descrittori Tx alla scheda di rete, un guest li scrive nel Tx Ring. Questo è un buffer circolare che risiede in memoria fisica a un indirizzo predefinito. Quando tutti i descrittori sono stati scritti nel Tx Ring, il guest aggiorna il registro MMIO TDT (Transmit Descriptor Tail) di E1000 per comunicare all'host che ci sono nuovi descrittori da gestire.

Input

Considera il seguente array di descrittori Tx:``` [context_1, data_2, data_3, context_4, data_5]

Assegniamo i loro campi di struttura come segue (i nomi dei campi sono ipotetici, per essere leggibili dall'uomo, ma mappano direttamente alla specifica 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

We will learn why they should be like that in our step-by-step analysis.

Root Cause Analysis

[context_1, data_2, data_3] Processing

Let's assume the descriptors above are written to the Tx Ring in the specified order and TDT register is updated by the guest. Now the host will execute e1kXmitPending function in src/VBox/Devices/Network/DevE1000.cpp file (most of comments are and will be stripped for the sake of readability):```c static int e1kXmitPending(PE1KSTATE pThis, bool fOnWorkerThread) { ... while (!pThis->fLocked && e1kTxDLazyLoad(pThis)) { while (e1kLocateTxPacket(pThis)) { fIncomplete = false; rc = e1kXmitAllocBuf(pThis, pThis->fGSO); if (RT_FAILURE(rc)) goto out; rc = e1kXmitPacket(pThis, fOnWorkerThread); if (RT_FAILURE(rc)) goto out; }

e1kTxDLazyLoad leggerà tutti i 5 descrittori Tx dal Tx Ring. Poi e1kLocateTxPacket viene chiamata per la prima volta. Questa funzione itera attraverso tutti i descrittori per impostare uno stato iniziale ma non li gestisce effettivamente. Nel nostro caso, la prima chiamata a e1kLocateTxPacket gestirà i descrittori context_1, data_2 e data_3. I due descrittori rimanenti, context_4 e data_5, verranno gestiti alla seconda iterazione del ciclo while (tratteremo la seconda iterazione nella prossima sezione). Questa divisione dell'array in due parti è fondamentale per innescare la vulnerabilità, quindi vediamo perché.

e1kLocateTxPacket si presenta così:```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!"));
        }

Il primo descrittore (context_1) è di tipo E1K_DTYP_CONTEXT, quindi viene chiamata la funzione e1kUpdateTxContext. Questa funzione aggiorna un contesto di segmentazione TCP se la segmentazione TCP è abilitata per il descrittore. Per context_1 questa condizione è vera, quindi il contesto di segmentazione TCP verrà aggiornato. (Ciò che sia realmente l'aggiornamento del contesto di segmentazione TCP non è importante, e lo useremo solo per riferirci al codice sottostante).

Il secondo descrittore (data_2) è di tipo E1K_DTYP_DATA, quindi verranno eseguite alcune azioni non necessarie per la discussione.

Il terzo descrittore (data_3) è anch'esso di tipo E1K_DTYP_DATA, ma poiché data_3.data_length == 0 non viene eseguita alcuna azione.