[HN Gopher] Escaping VirtualBox 6.1: Part 1
___________________________________________________________________
Escaping VirtualBox 6.1: Part 1
Author : lima
Score : 132 points
Date : 2021-01-15 20:13 UTC (2 hours ago)
(HTM) web link (secret.club)
(TXT) w3m dump (secret.club)
| ExcavateGrandMa wrote:
| Oooooooffff :D
| m00dy wrote:
| Is this new Phrack or what ? :)
| vmcall wrote:
| 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 :)
| hhh wrote:
| You guys always have the best content (and design!)
| vmcall wrote:
| Thanks a lot, we put a lot of effort in to it so I am glad
| you like it
| SftwreEngnr wrote:
| Fuck off with the emoticons noob
| ThisIsTheWay wrote:
| 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/
| tyingq wrote:
| 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?
| hyper_reality wrote:
| 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...
| lima wrote:
| > _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.
| lrossi wrote:
| > 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.
___________________________________________________________________
(page generated 2021-01-15 23:00 UTC)