The exploit leverages a privilege escalation vulnerability in VirtualBox version 7.0.16. By exploiting this vulnerability, an attacker could elevate their privileges on the target system. The vulnerability is identified as CVE-2024-21111.
This exploit allows an unprivileged userspace process to escalate into the VirtualBox process, compromising the host kernel. It takes advantage of the loading of arbitrary shared libraries via dlopen() in the libasound library, which is loaded by the privileged VM host process for VMs with ALSA audio.
There is a vulnerability in VirtualBox that permits an attacker with root privileges in a virtual machine with a NAT network interface to corrupt the memory of the userspace host process and leak memory contents from the userspace host process. This probably permits an attacker with root privileges inside the guest to execute arbitrary code in userspace context on the host.
The hardened VirtualBox process on a Windows host doesn’t secure its COM interface leading to arbitrary code injection and EoP.
This exploit relies on the "/bin/sh" binary on the host as being a non-privilege dropping shell such as zsh, this is not always the OS default setting. It permits a malicious user to obtain root privileges on the VirtualBox host machine.
VirtualBox VM is unable to handle fast call to privilege level 0 system procedures (sysenter). If sysenter instruction is executed on the guest OS the host machine will reboot. The technique was tested on the following guest OS: Windows XP, Windows 7 RC, Ubuntu 9.04. It is not clear whether it is possible to execute arbitrary code on the host, however this trick can be successfully used by malware as an anti-vm trick.
This module exploits a vulnerability in the 3D Acceleration support for VirtualBox. The vulnerability exists in the remote rendering of OpenGL-based 3D graphics. By sending a sequence of specially crafted of rendering messages, a virtual machine can exploit an out of bounds array access to corrupt memory and escape to the host. This module has been tested successfully on Windows 7 SP1 (64 bits) as Host running Virtual Box 4.3.6.
Multiple memory corruption vulnerabilities have been found in the code that implements 3D Acceleration for OpenGL graphics in Oracle VirtualBox. These vulnerabilities could allow an attacker who is already running code within a Guest OS to escape from the virtual machine and execute arbitrary code on the Host OS.
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. On Windows mapped DLLs use an Image Section under the hood. This is a special type of file mapping where the parsing and relocating of the PE file is all handled by the kernel. To allow for sharing of image mappings (so ideally the kernel only needs to do the parsing and relocation once) the kernel memory manager ties the file object to an existing section object by using a unique section pointer set by the file system driver. The interesting thing about this is the section pointer doesn't necessarily ensure the file hasn't changed, just that the file system considered the file the 'same'. Therefore it's possible that opening a file and reading it returns a completely different PE file than the one you'll get if you then map that file as an image section.
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. The ring 3 process hardening in VirtualBox adds three hooks to module loading to try and prevent untrusted code being loaded into the process, LdrLoadDll, NtCreateSection and a LDR DLL notification. Each will try and verify a DLL load and either reject the load with an error or kill the process is it’s not possible to prevent it from occurring. Looking at the hooks there a couple of issues which when combined together allow a user to inject an arbitrary DLL into a protected process. The location checks are not very rigorous. As far as I can tell arbitrary files need to be owned by an admin/trustedinstaller but this check is waived if the file is in system32/WinSxS. However this doesn’t take into account that there are some directories which can be written to inside system32 such as Tasks. The code to enforce specific certificates doesn’t seem to be enabled so at the very least combined with 1, you can load any validly signed file. It might be considered that 2 isn’t an issue as getting a signing cert could be a sufficient burden for a “malicious” attacker, so instead it’s worth considering what else the weak path checking allows you to do. The handling of DLL paths has some interesting behaviours, most interestingly there’s the behaviour where if no file extension is added to the path then the loader will automatically append .DLL to it. This is actually imitated by the VirtualBox hooks, so if you pass a path without an extension then the hooks will also append .DLL to it. This means that if you can write a file to a directory which is in the system32 path then you can bypass the hooks and load arbitrary code.
Services By CQR