SSD Advisory – Oracle VirtualBox Multiple Guest to Host Escape Vulnerabilities
Credit to Author: SSD / Maor Schwartz| Date: Wed, 24 Jan 2018 14:11:46 +0000
Want to get paid for a vulnerability similar to this one?
Contact us at: sxsxdx@xbxexyxoxnxdxsxexcxuxrxixtxy.xcom
See our full scope at: https://blogs.securiteam.com/index.php/product_scope
Vulnerabilities summary
The following advisory describes two (2) guest to host escape found in Oracle VirtualBox version 5.1.30, and VirtualBox version 5.2-rc1.
Credit
An independent security researcher, Niklas Baumstark, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.
Vendor response
Oracle were informed of the vulnerabilities and released patches to address them.
For more details: http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html
CVE: CVE-2018-2698
Vulnerabilities details
The vulnerabilities found in the core graphics framework (VBVA subcomponent) and affect all host operating systems.
provide an arbitrary read/write primitive in the userland VirtualBox host rocess, relative to the guest’s VRAM buffer.
The VGA device emulated by VirtualBox is associated with a certain amount of VRAM, which is mapped contiguously in both the host process running the VM and in guest kernel memory.
Parts of it are used as general-purpose shared memory segment for communication between the host and guest (host-guest shared memory interface, HGSMI).
Using this mechanism, the guest can issue certain commands to the host, for example to implement the mouse pointer integration and seamless windows features.
The guest can also tell the host to copy data around inside the VRAM on its behalf, via a subsystem called VDMA.
Out-of-bounds read/write in vboxVDMACmdExecBpbTransfer
The VBOXVDMACMD_DMA_BPB_TRANSFER
command struct looks as follows (defined in include/VBox/VBoxVideo.h:1435
):
When issuing a VDMA command of type VBOXVDMACMD_TYPE_DMA_BPB_TRANSFER
, a request object of this type resides in the HGSMI heap and is completely controlled by the guest.
On the host, a pointer to the object is eventually passed to the following function inside the file src/VBox/Devices/Graphics/DevVGA_VDMA.cpp
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 | static int vboxVDMACmdExecBpbTransfer(PVBOXVDMAHOST pVdma, const PVBOXVDMACMD_DMA_BPB_TRANSFER pTransfer, uint32_t cbBuffer) { // … uint32_t cbTransfer = pTransfer->cbTransferSize; uint32_t cbTransfered = 0; // … do { uint32_t cbSubTransfer = cbTransfer; if (pTransfer->fFlags & VBOXVDMACMD_DMA_BPB_TRANSFER_F_SRC_VRAMOFFSET) { // [[ Note 1 ]] pvSrc = pvRam + pTransfer->Src.offVramBuf + cbTransfered; } else { // … } if (pTransfer->fFlags & VBOXVDMACMD_DMA_BPB_TRANSFER_F_DST_VRAMOFFSET) { // [[ Note 2 ]] pvDst = pvRam + pTransfer->Dst.offVramBuf + cbTransfered; } else { // … } if (RT_SUCCESS(rc)) { memcpy(pvDst, pvSrc, cbSubTransfer); cbTransfer -= cbSubTransfer; cbTransfered += cbSubTransfer; } else { cbTransfer = 0; /* to break */ } // … } while (cbTransfer); if (RT_SUCCESS(rc)) return sizeof (*pTransfer); return rc; } |
Note 1 and 2: the guest-controlled offsets pTransfer->Src.offVramBuf
and pTransfer->Dst.offVramBuf
are added to the VRAM address, without any verification or bounds checks.
A memcpy is then performed with the guest-controlled size pTransfer->cbTransferSize
.
This gives us a memcpy(VRAM + X, VRAM + Y, Z)
primitive, where we (as the guest)can chose X
, Y
and Z
arbitrarily.
Out-of-bounds read/write in vboxVDMACmdExecBlt
The VBOXVDMACMD_DMA_PRESENT_BLT
command struct looks as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | typedef uint64_t VBOXVIDEOOFFSET; /* […] */ typedef struct VBOXVDMACMD_DMA_PRESENT_BLT { VBOXVIDEOOFFSET offSrc; VBOXVIDEOOFFSET offDst; VBOXVDMA_SURF_DESC srcDesc; VBOXVDMA_SURF_DESC dstDesc; VBOXVDMA_RECTL srcRectl; VBOXVDMA_RECTL dstRectl; uint32_t u32Reserved; uint32_t cDstSubRects; VBOXVDMA_RECTL aDstSubRects[1]; } VBOXVDMACMD_DMA_PRESENT_BLT, *PVBOXVDMACMD_DMA_PRESENT_BLT; |
When issuing a VDMA command of type VBOXVDMACMD_TYPE_DMA_PRESENT_BLT
, a request object of this type resides in the HGSMI heap and is completely controlled by the guest.
On the host, a pointer to the object is eventually passed to the following function inside the file src/VBox/Devices/Graphics/DevVGA_VDMA.cpp
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | static int vboxVDMACmdExecBlt(PVBOXVDMAHOST pVdma, const PVBOXVDMACMD_DMA_PRESENT_BLT pBlt, uint32_t cbBuffer) { const uint32_t cbBlt = VBOXVDMACMD_BODY_FIELD_OFFSET(uint32_t, VBOXVDMACMD_DMA_PRESENT_BLT, aDstSubRects[pBlt->cDstSubRects]); Assert(cbBlt <= cbBuffer); if (cbBuffer < cbBlt) return VERR_INVALID_FUNCTION; /* we do not support stretching for now */ Assert(pBlt->srcRectl.width == pBlt->dstRectl.width); Assert(pBlt->srcRectl.height == pBlt->dstRectl.height); if (pBlt->srcRectl.width != pBlt->dstRectl.width) return VERR_INVALID_FUNCTION; if (pBlt->srcRectl.height != pBlt->dstRectl.height) return VERR_INVALID_FUNCTION; Assert(pBlt->cDstSubRects); /* [[ Note 2 ]] */ uint8_t * pvRam = pVdma->pVGAState->vram_ptrR3; VBOXVDMA_RECTL updateRectl = {0, 0, 0, 0}; if (pBlt->cDstSubRects) { /* […] */ } else { /* [[ Note 1 ]] */ int rc = vboxVDMACmdExecBltPerform(pVdma, pvRam + pBlt->offDst, pvRam + pBlt->offSrc, &pBlt->dstDesc, &pBlt->srcDesc, &pBlt->dstRectl, &pBlt->srcRectl); AssertRC(rc); if (!RT_SUCCESS(rc)) return rc; vboxVDMARectlUnite(&updateRectl, &pBlt->dstRectl); } return cbBlt; } |
At Note 1, the guest-controlled offsets pBlt->offDst
and pBlt->offSrc
I added to the VRAM address, without any verification. Note that the assert at Note 2 is not active in production builds, so we can reach the else-branch.
vboxVDMACmdExecBltPerform
then performs a memcpy between the computed addresses:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | static int vboxVDMACmdExecBltPerform(PVBOXVDMAHOST pVdma, uint8_t *pvDstSurf, const uint8_t *pvSrcSurf, const PVBOXVDMA_SURF_DESC pDstDesc, const PVBOXVDMA_SURF_DESC pSrcDesc, const VBOXVDMA_RECTL * pDstRectl, const VBOXVDMA_RECTL * pSrcRectl) { /* [...] /* if (pDstDesc->width == pDstRectl->width && pSrcDesc->width == pSrcRectl->width && pSrcDesc->width == pDstDesc->width) { Assert(!pDstRectl->left); Assert(!pSrcRectl->left); uint32_t cbOff = pDstDesc->pitch * pDstRectl->top; uint32_t cbSize = pDstDesc->pitch * pDstRectl->height; memcpy(pvDstSurf + cbOff, pvSrcSurf + cbOff, cbSize); } else { /* [...] /* } return VINF_SUCCESS; } |
By setting pDstDesc->pitch = 1
, pDstRectl->top = 0
, we can get cbOff = 0
and cbSize = pDstRectl->height
(which we also control as the guest).
This ends up in a call to memcpy(VRAM + X, VRAM + Y, Z)
, where we can chose X
, Y
and Z
arbitrarily.
Proof of Concept
We will modified vboxvideo kernel module to trigger the bug.
The modified module will allow us to creates a device /dev/vboxpwn
which can be used to send arbitrary VBVA commands via its ioctl()
handler.
In this PoC we will use 64-bit Ubuntu VM.
First we will download the VBoxGuestAdditions:
1 2 3 | $ wget http://download.virtualbox.org/virtualbox/5.1.30/VBoxGuestAdditions_5.1.30.iso $ sudo mount –o loop –t iso9660 VBoxGuestAdditions_5.1.30.iso /mnt $ sudo /mnt/VBoxLinuxAdditions.run |
Then we will upload the modified files – HGSMIBase.c
and 70-vboxpwn.rules
to the home directory of the VM and rebuild the extensions with the modified code:
1 2 3 4 5 | $ sudo cp 70–vboxpwn.rules /etc/udev/rules.d $ sudo cp HGSMIBase.c /usr/src/vboxguest–5.1.30/vboxvideo $ sudo /mnt/VBoxLinuxAdditions.run —keep —target additions —noexec $ sudo additions/vboxadd setup $ sudo reboot |
There should now be a new device called /dev/vboxpwn
with 0666 permissions.
Now create the following Python script called poc.py
: