Monorail Project: project-zero Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 3 users
Status: Fixed
Closed: Apr 19

Sign in to add a comment
VirtualBox: Windows Process COM Injection EoP
Project Member Reported by, Jan 27 2017 Back to list
VirtualBox: Windows Process COM Injection EoP
Platform: VirtualBox v5.0.32 r112930 x64 (Tested on Windows 10)
Class: Elevation of Privilege

The process hardening implemented by the VirtualBox driver can be circumvented to load arbitrary code inside a VirtualBox process giving access to the VBoxDrv driver which can allow routes to EoP from a normal user.


NOTE: I don’t know if you consider this an issue or not, considering the power of accessing the VBoxDrv driver and the efforts you’re going to to block access I’d assume it is.

VirtualBox uses a number of different techniques to prevent untrusted code accessing the core system drivers. This is because most of VB runs as a non-admin user but the driver provides a number of privileged features such as allocating kernel memory and loading drivers. This process hardening is implemented in both the kernel driver (which prevents things like getting fully privileged handles to a VB process) and in user mode by hooking the library loader to block untrusted DLLs. 

Obviously if you could run untrusted code inside the main VirtualBox.exe process it would potentially lead to kernel code execution. Therefore it’d be interesting to bypass. Looking at VirtualBox.exe when it runs it loads a number of COM objects into memory. Due to the way COM works it’s possible to register a per-user version of an object (by it’s unique CLSID) and that’s taken in preference to the system wide version. As all VB processes run under the user’s identity we can replace a class registration (such as for the VirtualBox Client COM server) and the started copy of VirtualBox.exe will try and load our code instead.

The trick is bypassing the signature checking process, we can’t just insert our own DLLs, so we must repurpose something which is already trusted, like most of the Microsoft signed binaries in Windows. The simplest attack vector is to use the Scriptlet Component COM server implemented in scrobj.dll. This allows us to register a COM object which instead of being implemented as a DLL is implemented in a scripting language such as JScript or VBScript. As scrobj.dll is verified as a signed MS binary it will load, however we get code execution inside the process through a JScript file which isn’t verified on a default Windows system.

Of course JScript isn’t enough to call methods on the VBoxDrv driver so we need a way of breaking out of the restrictive script environment. You could perhaps find a buggy COM object and use that to ROP your way out, but there’s an easier way. The core parts of .NET (such as mscoree, mscorwks, mscorlib) are trusted binaries, so using some of the .NET COM registrations we can use .NET from JScript to bootstrap full .NET where we can do anything, such as calling arbitrary methods through P/Invoke. We can’t just register a .NET COM object though as .NET loads most DLLs via standard library loading which will be blocked by the signature checking, so instead we force .NET to load an assembly from a byte array which the process hardening code never sees.

From a fixing perspective I’m sure there’s always going to be edge cases but you’d probably want to blacklist certain DLLs such as scrobj/jscript/vbscript etc. and also anything .NET related.

Proof of Concept:

I’ve provided a PoC as a scriptlet file and a registry reg script. When combined together the scriptlet replaces the VirtualBox Client COM server (CLSID: {DD3FC71D-26C0-4FE1-BF6F-67F633265BBA}) so when VirtualBox.exe tries to load it instead it gets a JScript implementation which bypasses the signature checking (as scrobj.dll/jscript.dll etc are MS signed system binaries). It then gets full execution by bootstrapping some arbitrary .NET code from memory (so there’s no DLL to verify) so that it can call exported library functions and access the VirtualBox driver. 

You’ll need .NET 3.5 installed for the PoC to work. This isn’t strictly necessary you could register the appropriate COM classes for .NET 4 but no point polluting the registry even more. You need a configured VM to start.

1) Ensure that .NET 3.5 is installed. Otherwise the PoC will prompt you to install.
2) Copy poc.sct to the directory c:\poc so you have a file c:\poc\poc.sct on the local disk.
3) Start a VM using VBoxManage startvm "VM Name" (don’t use the GUI as that’ll also load our COM object which won’t work very well).
4) A message box should appear showing two memory addresses (which are the result of calling SUPR3PageAllocEx). The message box should be being displayed from the “unrestricted” VirtualBox.exe process.

Expected Result:
Loading Scriptlet code into memory should fail

Observed Result:
Scriptlet code is loaded and access to the device driver is allowed.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.
4.5 KB Download
Project Member Comment 1 by, Jan 27 2017
For some reason the updater didn't recommend the actual latest version of VirtualBox when I tested this. I've run the exploit against 5.1.14 and it does still work.
Project Member Comment 2 by, Jan 27 2017
After more of of a look seems 5.1 is a major update so doesn't always get recommend. 5.0.32 is the latest version of the 5.0 branch which was updated on 2017/1/17 so is current.
Project Member Comment 3 by, Jan 27 2017
Labels: Oracle-S0824186
Project Member Comment 4 by, Apr 16
Labels: CVE-2017-3563
Oracle are expecting to release a fix for this on 18/04/2017.
Project Member Comment 6 by, Apr 19
Labels: -Restrict-View-Commit
I've been experimenting with this on 32/64-bit Win7 and Win8 and found that VBoxManager will reset the DLL path in HKCU before VirtualBox.exe instantiates the (supposedly) hijacked COM object. This makes exploitation very unreliable - I could only trigger the memory read once in dozens of runs. 

Although there is an obvious (and quite large) TOCTOU window to exploit I found that the HKCU fix doesn't happen again if a VM has already been started. You can start a VM, run the registry script then launch the same VM again - the second time always the malicious HKCU values are used (before VirtualBox would check for locks on the VM).
Sign in to add a comment