CVE-2017-3563 : Detail

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1103 VirtualBox: Windows Process COM Injection EoP Platform: VirtualBox v5.0.32 r112930 x64 (Tested on Windows 10) Class: Elevation of Privilege Summary: 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. Description: 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. Prerequisites: 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. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41908.zip