Escaping VirtualBox 6.1: Part 1 | Hacker News Reader

Escaping VirtualBox 6.1: Part 1

secret.club

324 pointslima46 comments

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 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.

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.

KVM and QEMU maintainer here.

> most stock QEMU-KVM deployments simply run qemu as root with no extra sandboxing or MAC like SELinux/sVirt.

This is not true. OpenStack uses Libvirt for example, so on Red Hat/CentOS systems it will be hardened with SELinux by default. The same is true for virt-manager, which runs as either an unprivileged "qemu" user or as the user that invokes it.

Not all the code in QEMU is of identical quality, but the subset that is used by cloud providers is very mature and is also tested in Google's open source fuzzing cluster. Thanks to a student from Boston University who came up with some pretty cool techniques, we can cover devices effectively without having to teach the fuzzer about each device's registers.

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

Two of them--certainly they are the big ones, Amazon and Google, but pretty much everybody else is using QEMU. For what it's worth, Amazon is also using QEMU on their old Xen-based instance types.

Firecracker is the only open source virtual machine monitor that cloud providers use in production apart from QEMU, as far as I know. It's a very interesting project and the people behind it have also started rust-vmm, a library of Rust crates for virtual machine monitors and device emulation backends. Several QEMU developers also contribute to rust-vmm, focusing especially on the abstractions needed to avoid unsafe code in virtual machine monitors. There was already an instance last year of problematic unsafe code in Firecracker that wouldn't have been there had it used rust-vmm's vm-memory crate, and in fact Firecracker has since switched to vm-memory. So there is plenty of collaboration between the authors of various VMMs.

> Thanks to a student from Boston University who came up with some pretty cool techniques, we can cover devices effectively without having to teach the fuzzer about each device's registers.

Can I ask who this was and is there any more info on their work? Seems important and worth naming them :)

Alexander Bulekov. You can find their work in the git log but I think there's no published paper yet.

> Many cloud providers use KVM-the-kernel-module, but an in-house replacement for QEMU.

Which are typically closed source, which is quite a shame.

If you're using KVM within a single organization to compartmentalize VMs, but they are all ultimately administered by the same people and toolchain, the threat is much less.

A lot of the extensive security precautions for qemu are intended for a hosting provider threat model where multiple random tenant customers may be using VMs on the same hypervisor bare metal, in which case you absolutely don't want them to be able to escape the vm or read each others' memory.

crosvm by Chrome OS is open source. And was even used / forked by Amazon cloud. It's Rust based.

Small correction: gVisor does not use KVM under the hood. It intercepts and filters the applications system calls, acting as a sort of userspace hypervisor.

It does, you can choose between ptrace and kvm in the config.

Didn't know it supports KVM as well. I though it only supports ptrace, as that's how it was advertised. This is cool!

What do you mean by kvm being audited exhaustively? Would be interesting to read about this.

It has been tested by the syzkaller fuzzing tool for years, and Google has done extensive search for vulnerabilities in the code (they did find some!).

>> but some people really do think that VirtualBox VMs act like a sandbox, which is only true if your adversary is rather unsophisticated.

Nation states are one thing.

Will it protect the average user, against common security risks ?

No one is going to risk exposing extremely valuable zero days just to root your box unless you have something really valuable on it.

That makes sense.

But every security bug starts as a zero day. But yet some bugs become common malware, yet I others are not.

Why?

And is virtualization somehow special in that regard?

CTF = Capture the Flag?

Yes, it's sort of a hacking competitipn where you have to read out a "flag" which can then be submitted aa solution.

https://en.wikipedia.org/wiki/Wargame_%28hacking%29?wprov=sf... (mentioned in 2nd paragraph)

And I thought I was joking :-)

Hey, I played in that CTF! Although, I ended up spending most of my time pwning QEMU instead. There was an easier challenge, aptly named Easy Escape, in which the organizers added a vulnerable memory-mapped device to QEMU. The device had the ability to read and write certain memory, so the exploit ended up being an attack where you triggered a memory operation which accessed the device's own memory - essentially causing the device's MMIO handler to recurse. That in turn set up a use-after-free situation which could be exploited for the win.

I love Real World CTF. In 2018 I participated in the finals round held in Zhengzhou, and there was a problem that involved Java and the RMI protocol. We ended up exploiting two zero-days in Java, reported them to Oracle and got a CVE: CVE-2019-2684. That was very exciting to me - to discover and exploit a bug in real software in less than 48 hours :)

Kudos to the VirtualBox hackers for doing that on such a high-profile bit of software - amazing work!

Just a question:

Do the organizers know about the security vulnerability?

Where do they get the vulnerabilities from?

Lots of CTF organizers are security researchers. This particular CTF is organized by people from Chaitin Tech, which is a cybersecurity company. They emphasize that their challenges are based on real vulnerabilities (found in their research, I presume).

The QEMU task was likely inspired by a real vulnerability as well: https://mail.gnu.org/archive/html/qemu-devel/2020-09/msg0090... (discovered by CTF organizers, I think)

Are these CTFs recorded and/or streamed? It just occurred to me that would be really fun to watch.

CTFs are not usually streamed, as that would give a leg up to other teams watching it :P Not sure if anyone records their work for later viewing, though.

You might like LiveOverflow 's video about playing the Google CTF finals hackceler8: https://www.youtube.com/watch?v=DGuRI_SPZYg

I'm a complete noob when it comes to CTF, but escaping a VM to control the host is total witchcraft to me. Darknet Diaries just had a great podcast on the Pwn2Own CTF hosted by CanSecWest cyber-security conference, which includes a competition to escape a virtualized machine. Highly recommended, it's a great listen.

https://darknetdiaries.com/episode/82/

The details are witchcrafty to me, but the base idea that virtual devices passed to the guest can have unintended access to host memory (or files, etc) seems straightforward.

Edit: Curious, are there common guest escapes that exploit something other than virtual devices?

Core hypervisor code may have a bug that can be triggered via the kvm API.

The guest-host API is just attack surface like any other (file formats, network protocols, kernel syscall api, browser sandbox etc) and typically the privileged side is implemented in memory-unsafe languages.

As bugs in memory-unsafe PL code have high probability to be exploitable, giving control to the attacker, the game is set.

Is this new Phrack or what ? :)

We don't strive to be the new Phrack, we just needed our own platform where we would ensure high-quality submissions without any ads :)

I absolutely adore this website, please keep up the great work. When I first ran into it a few months ago I had to binge-read every article, it was too fascinating to stop.

You guys always have the best content (and design!)

Thanks a lot, we put a lot of effort in to it so I am glad you like it

This is making me interested in security again!!!

If it's a vuln in the latest available version, was it reported to the vendor before the blog post?

Most of the VM escapes I've seen exploit virtual devices rather than the hypervisor itself.

Presumably it might be a good idea to do a better job isolating the virtual devices. Might be nice to use a memory safe language/runtime also.

Looks like there a typo in the exploit() function?

They have this variable declaration in the beginning: static const short port_base = 0x434;

However they use "port" variable when making calls: __outbyte(port+3, 0);

Does anyone know how to prevent a guest os to detect its running in a VM ? I tried online but got no satisfactory results. Anyone?

Maybe it's an in-joke, but this website is too dark to read

Did you tried NoScript? It's very white for me, but in my case NoScript and uBlock Origins are my default for surfing web.

Can you tell me what device you are on?

Ipad4, it happens on both safari and chrome

"so the impact is very limited"

dropping in on this as an outsider but this looks like juat a(nother) windows vulnerability

Reply on news.ycombinator.com