Full Report
The author of this post decided to take a trip down memory lane by reviewing a vulnerability they found in VirtualBox 5 years ago. The post is heavy into the methodology, which I always appreciate! While doing recon and looking at previous research, they came to the conclusion that the VBVA (Virtual Box Video Acceleration) was good to look at. Why? One thing is that video subsystems are known to be hard to implement securely not just in VBox but other virtualization software as well. This is because they are many handling of pointers, offsets and things, which can lead to memory corruption. To look at the source code, they decided to look for sources. Any input that was directed controlled by users within the virtual machine was considered. They were curious about how integers overflows were being prevented. One way of doing this is by saving the result of two smaller integers into a single integer, such as uint16_t into uint32_t. Although this is fine in most cases, there is an additional multiplication by 4, that can lead to an overflow occurring. What can we do with this? The height * width * 4 value is used for a sanity check to ensure we're not writing outside the bounds of the VRAM buffer. However, since this check will overflow, we can cause memory corruption in future writes. They noticed that the function crMClrFillMem() for filling in a rectangle img can be used to write outside of the buffer! The OOB write has a controlled value and a controlled offset, which is an amazing primitive. This also grants an OOB via the same bug. Overall, a good post on the discovery of a super powerful vulnerability within VBox. To me, I don't like the preventative strategy of overflows used, as it seems prone to errors with extra addition being done.
Analysis Summary
# Vulnerability: VirtualBox Video Acceleration (VBVA) Integer Overflow to OOB Write
## CVE Details
- **CVE ID:** CVE-2019-2703
- **CVSS Score:** 8.8 (High) - *Note: Based on typical VM escape ratings for this period.*
- **CWE:** CWE-190 (Integer Overflow), CWE-787 (Out-of-bounds Write)
## Affected Systems
- **Products:** Oracle VM VirtualBox
- **Versions:** Versions prior to 6.0.6 (e.g., 6.0.4)
- **Configurations:** Systems with Guest Additions or VBVA (Virtual Box Video Acceleration) enabled/reachable.
## Vulnerability Description
The vulnerability exists within the VBVA subsystem, specifically in the handling of video rectangle operations. To prevent overflows, the code attempts to save the result of two smaller integers into a larger integer (e.g., `uint16_t` dimensions into a `uint32_t`).
However, a subsequent multiplication by 4 (required for 32-bit pixel depth calculations) occurs during a sanity check meant to ensure writes stay within the VRAM buffer. This multiplication can cause an integer overflow, resulting in a small value that bypasses the bounds check. This leads to an **Out-of-Bounds (OOB) Write** in functions such as `crMClrFillMem()`.
## Exploitation
- **Status:** PoC Available / Documented.
- **Complexity:** Medium (Requires interaction with specific guest-to-host communication channels).
- **Attack Vector:** Local (Triggered by a privileged or malicious user within the Guest VM to escape to the Host).
## Impact
- **Confidentiality:** High (Potential to read host memory via OOB primitives).
- **Integrity:** High (Memory corruption allows for arbitrary code execution on the host OS).
- **Availability:** High (Host process crash/DoS).
## Remediation
### Patches
- Users should update to **VirtualBox 6.0.6**, **5.2.28**, or later versions where the integer overflow check was corrected.
### Workarounds
- Disable 3D acceleration features if not required.
- Untrusted guests should be isolated and monitored; however, software updates remain the only definitive fix.
## Detection
- **Indicators of Compromise:** Unusual memory access patterns or crashes in the `VirtualBox.exe` (or `VirtualBoxVM`) process on the host.
- **Detection Methods:** Monitoring for unauthorized calls to the VBVA subsystem or use of specialized kernel modules within the guest designed to communicate with the `VBoxGuest` device.
## References
- **Vendor Advisory:** hxxps[://]www[.]oracle[.]com/security-alerts/cpuapr2019[.]html
- **Researcher Blog:** hxxps[://]j0nathanj[.]github[.]io/post/vbox_escape/
- **Related Research:** hxxps[://]www[.]exploit-db[.]com/exploits/43878