This is impressive work.

First it shows how the top CTFs can showcase the state of the art in terms of exploitation. It's hard for anyone to argue that the CTF scene does not reflect the "real world" when it is producing solid work like unpublished virtual machine escapes. And even better, the work is shared in high quality writeups.

Secondly, this plus other vulnerabilities found in VirtualBox emphasises that off-the-shelf hypervisors cannot be considered to create a security boundary. Every serious nationstate possess weaponised exploits to break out of VirtualBox, VMware etc. KVM and Xen have a smaller attack surface and are known to have a better isolation model, but I'm sure there are still plenty of exploits given enough resources. Perhaps this is obvious to some, but some people really do think that VirtualBox VMs act like a sandbox, which is only true if your adversary is rather unsophisticated.

For a writeup from the same CTF, but focussing on networking and cryptography instead involving an exploit in a Chinese anti-censorship proxy tunnel, please see https://blog.cryptohack.org/cracking-chinese-proxy-realworld...

KVM - the low-level kernel-level hypervisor - has a tiny attack surface and has been audited exhaustively. It's unlikely to have critical bugs in it.

When people talk about "KVM vulnerabilities", they're usually talking about vulnerabilities in QEMU, which implements the actual device emulation. QEMU has all of the attack surface, deals with low-level data shuffling, and is written in C. Even worse, most stock QEMU-KVM deployments simply run qemu as root with no extra sandboxing or MAC like SELinux/sVirt. It's very likely that a bunch of 0days exist for those environments.

This is why many cloud providers use KVM-the-kernel-module, but an in-house replacement for QEMU.

Fortunately, there's a growing ecosystem of QEMU replacements written in Rust:

- https://github.com/cloud-hypervisor/cloud-hypervisor

- https://github.com/firecracker-microvm/firecracker

- https://chromium.googlesource.com/chromiumos/platform/crosvm... (the Chrome OS VM runtime which Firecracker was forked from)

Google's gVisor - the sandbox that App Engine and Cloud Run uses - uses KVM as well: https://gvisor.dev/docs/

With an emulation layer written in a language like Rust, the trust boundary is much better.

As for VirtualBox in particular - that one should not be considered a trust boundary. Nobody is seriously using it in production, and it's regularly featured in CTF competitions as a fun exploitation target.