Exploit-DB #6218
Description: Sun xVM VirtualBox < 1.6.4 - Privilege Escalation (PoC)
Type: dos
Platform: multiple
Date: 2008-08-10
Author: Core Security

Exploit:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

      Core Security Technologies - CoreLabs Advisory
           http://www.coresecurity.com/corelabs/


  Sun xVM VirtualBox Privilege Escalation Vulnerability


*Advisory Information*

Title: Sun xVM VirtualBox Privilege Escalation Vulnerability
Advisory ID: CORE-2008-0716
Advisory URL:
http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability

Date published: 2008-08-04
Date of last update: 2008-08-04
Vendors contacted: Sun Microsystems
Release mode: Coordinated release


*Vulnerability Information*

Class: Insufficient input validation

Remotely Exploitable: No
Locally Exploitable: Yes
Bugtraq ID: 30481	
CVE Name: CVE-2008-3431	


*Vulnerability Description*

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
environments.

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 Packages*

. Sun xVM VirtualBox 1.6.2.

. Sun xVM VirtualBox 1.6.0.
. This issue only occurs in the Microsoft Windows versions of xVM
VirtualBox.


*Non-vulnerable Packages*

. Sun xVM VirtualBox 1.6.4 (for Microsoft Windows)



*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.



*Credits*

This vulnerability was discovered and researched by Anibal Sacco from
the CORE IMPACT Exploit Writing Team (EWT) at Core Security Technologies.


*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 sente