[NEWS] Sun xVM VirtualBox Privilege Escalation Vulnerability
- From: SecuriTeam <support@xxxxxxxxxxxxxx>
- Date: 5 Aug 2008 11:05:17 +0200
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 
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 .
When used on a Windows Host Operating System VirtualBox installs a kernel
driver ('VBoxDrv.sys') to control virtualization of guest
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.
* Sun xVM VirtualBox version 1.6.2
* Sun xVM VirtualBox version 1.6.0
* 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);
PSUPDRVSESSION pSession =
* 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;
if ( ulCmd == SUP_IOCTL_FAST_DO_RAW_RUN
(1) || ulCmd == SUP_IOCTL_FAST_DO_HWACC_RUN
|| ulCmd == SUP_IOCTL_FAST_DO_NOP)
/* Raise the IRQL to DISPATCH_LEVEl to prevent Windows from
rescheduling us to another CPU/core. */
Assert(KeGetCurrentIrql() <= DISPATCH_LEVEL);
(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));
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:
#define SUP_IOCTL_FAST_DO_RAW_RUN SUP_CTL_CODE_FAST(64)
/** Fast path IOCtl: VMMR0_DO_HWACC_RUN */
#define SUP_IOCTL_FAST_DO_HWACC_RUN SUP_CTL_CODE_FAST(65)
/** Just a NOP call for profiling the latency of a fast ioctl call to
#define SUP_IOCTL_FAST_DO_NOP SUP_CTL_CODE_FAST(66)
With the macro 'SUP_CTL_CODE_FAST()' defined in the same file:
#define SUP_CTL_CODE_FAST(Function) CTL_CODE(FILE_DEVICE_UNKNOWN,
| SUP_IOCTL_FLAG, METHOD_NEITHER,
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
// Organization: Core Security Technologies
int main(int argc, char **argv)
char szDevice = "\\\\.\\VBoxDrv";
if ( (hDevice = CreateFileA(szDevice,
NULL) ) != INVALID_HANDLE_VALUE )
printf("Device %s succesfully opened!\n", szDevice);
printf("Error: Error opening device %s\n",szDevice);
cb = 0;
printf("Error in DeviceIo ... bytes returned %#x\n",cb);
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
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.
 Sun Welcomes Innotek - <http://www.sun.com/software/innotek/>
Vendor Information, Solutions and Workarounds:
No workarounds exist for this issue. A security bulletin from the vendor
that describes this issue is available here:
The information has been provided by <mailto:advisories@xxxxxxxxxxxxxxxx>
CORE Security Technologies Advisories.
The original article can be found at:
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.
- Prev by Date: [UNIX] Ingres Database for Linux Multiple Vulnerabilities
- Next by Date: [UNIX] Apple Mac OS X CoreGraphics PDF Type1 Font Integer Overflow Vulnerability
- Previous by thread: [UNIX] Ingres Database for Linux Multiple Vulnerabilities
- Next by thread: [UNIX] Apple Mac OS X CoreGraphics PDF Type1 Font Integer Overflow Vulnerability