[NEWS] Sun xVM VirtualBox Privilege Escalation Vulnerability

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.

- - - - - - - - -

Sun xVM VirtualBox Privilege Escalation Vulnerability


Virtualization technologies allow users to run different operating systems
simultaneously on top of the same set of underlying physical hardware.
This provides several benefits to end users and organizations, including
efficiency gains in the use of hardware resources, reduction of
operational costs, dynamic re-allocation of computing resources and rapid
deployment and configuration of software development and testing

VirtualBox is an open source virtualization technology project originally
developed by Innotek, a software company based in Germany.

In February 2008 Sun Microsystems announced the acquisition of Innotek [1]
and VirtualBox was integrated into Sun's xVM family of virtualization
technologies. In May 2008, Sun Microsystems announced that the number of
downloads of the open source VirtualBox software package passed the five
million mark [2].

When used on a Windows Host Operating System VirtualBox installs a kernel
driver ('VBoxDrv.sys') to control virtualization of guest
Operating Systems.

An input validation vulnerability was discovered within VirtualBox's
'VBoxDrv.sys' driver that could allow an attacker, with local but
un-privileged access to a host where VirtualBox is installed, to execute
arbitrary code within the kernel of the Windows host operating system and
to gain complete control of a vulnerable computer system.


Vulnerable Systems:
* Sun xVM VirtualBox version 1.6.2
* Sun xVM VirtualBox version 1.6.0

Immune Systems:
* Sun xVM VirtualBox version 1.6.4

Technical Description / Proof of Concept Code:
When the VirtualBox package is installed on a host the 'VBoxDrv.sys'
driver is loaded on the machine. This driver allows any unprivileged user
to open the device '\\.\VBoxDrv' and issue IOCTLs with a buffering mode of
METHOD_NEITHER without any kind of validation. This allows untrusted user
mode code to pass arbitrary kernel addresses as arguments to the driver.

With specially constructed input, a malicious user can use functionality
within the driver to patch kernel addresses and execute arbitrary code in
kernel mode. When handling IOCTLs a communication method must be
pre-defined between the user-mode application and the driver module. The
selected method will determine how the I/O Manager manipulates memory
buffers used in the communication.

The 'METHOD_NEITHER' is a very dangerous method because the pointer passed
to 'DeviceIoControl' as input or output buffer will be sent directly to
the driver, thus transferring it the responsibility of doing the proper
checks to validate the addresses sent from user mode.

The 'VBoxDrv.sys' driver uses the 'METHOD_NEITHER' communication method
when handling IOCTLs request and does not validate properly the buffer
sent in the Irp object allowing an attacker to write to any memory address
in the kernel-mode.

Let's see the bug on the source. This is the function used to handle the
IOCTL requests at 'SUPDrv-win.cpp'.


NTSTATUS _stdcall VBoxDrvNtDeviceControl(PDEVICE_OBJECT pDevObj, PIRP
PSUPDRVDEVEXT pDevExt = (PSUPDRVDEVEXT)pDevObj->DeviceExtension;
PIO_STACK_LOCATION pStack = IoGetCurrentIrpStackLocation(pIrp);

* Deal with the two high-speed IOCtl that takes it's arguments from
* the session and iCmd, and only returns a VBox status code.
ULONG ulCmd = pStack->Parameters.DeviceIoControl.IoControlCode;
KIRQL oldIrql;
int rc;

/* Raise the IRQL to DISPATCH_LEVEl to prevent Windows from
rescheduling us to another CPU/core. */
Assert(KeGetCurrentIrql() <= DISPATCH_LEVEL);
KeRaiseIrql(DISPATCH_LEVEL, &oldIrql);
(2) rc = supdrvIOCtlFast(ulCmd, pDevExt, pSession);

/* Complete the I/O request. */
NTSTATUS rcNt = pIrp->IoStatus.Status = STATUS_SUCCESS;
pIrp->IoStatus.Information = sizeof(rc);
(3) *(int *)pIrp->UserBuffer = rc;
rcNt = pIrp->IoStatus.Status = GetExceptionCode();
dprintf(("VBoxSupDrvDeviceContorl: Exception Code %#x\n", rcNt));
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return rcNt;

return VBoxDrvNtDeviceControlSlow(pDevExt, pSession, pIrp, pStack);


At (1), we can see the sentence checking the IOCTL code. The constants use
are defined at 'SUPDrvIOC.h' in this way:


/** Fast path IOCtl: VMMR0_DO_HWACC_RUN */
/** Just a NOP call for profiling the latency of a fast ioctl call to
VMMR0. */


With the macro 'SUP_CTL_CODE_FAST()' defined in the same file:




Now we know that the communication method used will be 'METHOD_NEITHER '
(this could also be easily seen by looking at the resulting IOCTL code in
the disassembled binary).

Then at (2) the value returned by 'supdrvIOCtlFast()' is saved in 'rc' and
this is where the problem starts because at (3), the value in 'rc' is
written directly to the buffer pointer sent from usermode without any
check to validate that it is really pointing to an usermode address or
even a valid one.

In this scenario, it is possible to feed the IOCTL with kernel addresses
to write the value returned by 'supdrvIOCtlFast()' ANY address in kernel
space memory as many times as necessary to modify kernel code or kernel
pointers to subsequently get code execution in ring 0 context (that means,
with system privileges).

This is the Proof of Concept Anibal has made to trigger and show the
vulnerability. This will generate a Blue Screen of Death (BSOD) trying to
write to an unpaged kernel mode address (0x80808080) but any other
arbitrary address could be used.


// Author: Anibal Sacco (aLS)
// Contact: anibal.sacco@xxxxxxxxxxxxxxxx
// anibal.sacco@xxxxxxxxx
// Organization: Core Security Technologies

#include <windows.h/>
#include <stdio.h/>

int main(int argc, char **argv)
HANDLE hDevice;
char szDevice[] = "\\\\.\\VBoxDrv";

if ( (hDevice = CreateFileA(szDevice,
printf("Device %s succesfully opened!\n", szDevice);
printf("Error: Error opening device %s\n",szDevice);

cb = 0;
if (!DeviceIoControl(hDevice,
printf("Error in DeviceIo ... bytes returned %#x\n",cb);


Report Timeline:
2008-07-16: Core Security Technologies notifies the VirtualBox team of the
2008-07-17: Vendor acknowledges notification.
2008-07-29: Core asks the vendor for a status update in the fixing
2008-07-30: Vendor notifies a patched version will be publicly available
on Monday 4th, August.
2008-07-31: Core asks the vendor to provide URL to their alert and to
confirm which versions are vulnerable and which version will include the
2008-07-31: CVE ID request sent to Mitre.
2008-07-31: Bugtraq ID request sent to SecurityFocus.com.
2008-07-31: CVE ID received from Mitre.
2008-07-31: Bugtraq ID received SecurityFocus.com.
2008-08-01: Vendor provides draft version of Sun Alert and URL to
reference it.
2008-08-01: Core updates its security advisory with information about
vulnerable and non-vulnerable packages. Core provides its URL to the
vendor and indicates that the vendor cataloged the issue as a Denial of
Service bug but it should be considered a privilege escalation problem
since it allows unprivileged users to execute code in the kernel context.
2008-08-04: Vendor confirms that this issue can lead to arbitrary code
execution by an unprivileged user.
2008-08-04: CORE-2008-0716 advisory is published.

[1] Sun Welcomes Innotek - <http://www.sun.com/software/innotek/>
[2] <http://www.sun.com/aboutsun/pr/2008-05/sunflash.20080529.1.xml>

Vendor Information, Solutions and Workarounds:
No workarounds exist for this issue. A security bulletin from the vendor
that describes this issue is available here:

CVE Information:


The information has been provided by <mailto:advisories@xxxxxxxxxxxxxxxx>
CORE Security Technologies Advisories.
The original article can be found at:
<http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability> http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages

  • [NT] Panda Internet Security/Antivirus+Firewall 2008 cpoint.sys Kernel Driver Memory Corruption
    ... Get your security news from a reliable source. ... Panda Internet Security/Antivirus+Firewall 2008 cpoint.sys Kernel Driver ... Some user controlled data is copied into ecx ... 2008/01/13 - Vendor response with PGP key ...
  • Re: Kernel 2.6.11
    ... > Linus releases code with known security holes. ... about downloading the sources and compiling my own kernel. ... served getting kernel sources supplied by their distrobution vendor. ... It is a simple statement that if Linus applies a security patch in his ...
  • [UNIX] Flaws Found in Recent Linux Kernels (newgrp, symblinks)
    ... Flaws Found in Recent Linux Kernels (newgrp, ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... An attacker can force the kernel to spend almost arbitrary amount of time ... script creates 5 symlinks, each of them containing 2*N+1 path elements. ...
  • [NEWS] Wonderware SuiteLink Denial of Service Vulnerability
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Get your security news from a reliable source. ... Vendor Information, Solutions and Workarounds ... Core sends the advisory draft to Wonderware support team. ...
  • [Full-Disclosure] Security Industry Under Scrutiny: Part 3
    ... > varying degrees of 'faith' in the security industry. ... site admins and other whitehats. ... > architect would be notifying the software vendor alone... ... Full disclosure isn't so much a tool to get vunerability information ...