... Loading ...

SSD Secure Disclosure

Disclosing vulnerabilities responsibly since 2007
Dark Theme

SSD Advisory – Oracle VirtualBox Multiple Guest to Host Escape Vulnerabilities

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:

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:

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:

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:

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:

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:

There should now be a new device called /dev/vboxpwn with 0666 permissions.
Now create the following Python script called poc.py:

If we will run it on a Linux host we will get the following:

The second read returns the header of the shared library mapped directly after the VRAM.
Of course we might crash the VM if we hit unmapped memory.
For demonstrating an absolute read/write, we need the VRAM base address on the host.
The findvram.py script find the VRAM base address – given the configured VRAM size.
In our case the VRAM is 33 MiB large.
The first argument is the PID of the host process (as shown above).
Also grab some absolute address you want to leak:

Back to the VM, we will read the ELF header of this library:

And now we will crash it by writing data to an unmapped address (make sure a debugger is attached):

The crash:

findvram.py

70-vboxpwn.rules

HGSMIBase.c

Print Friendly, PDF & Email