17

I would like to use VirtualBox to install some piece of software that should not have access to my host computer (and vice-versa). However, I also envision the possibility of attempting more "dangerous" stuff, like trying to run zero-day exploits and see what they can do.

How isolated can a virtual machine be made from the host? Should I (or can I?) set up a firewall between the guest and the host? Are guest add-ons a security risk? What about shared directories?

Right now, the guest machine is running GNU/Linux Debian testing.

  • 7
    Stack Exchange has a Information Security group if you want to ask detailed security questions. – cybernard Apr 5 '18 at 19:56
  • Seconding @cybernard here. After a bit of fleshing out, this would be an extremely appropriate question for Security.SE, assuming it's not a duplicate (which I'm afraid it might well be, given their community growth). – 0xdd Apr 5 '18 at 19:57
  • 1
    You should not use VirtualBox, because it interacts with your system through a kernel module which is a much higher risk than pure userspace implementations. And especially the virtual box kernel module is considered to be crap by the kernel developers. A better choice is some emulator like qemu running as an unprivileged user which does not have access to anything interesting and firewall rules which prevent network access for that user. (Posting as comment as it does not answer the question regarding VirtualBox directly) – allo Apr 6 '18 at 13:22
36

I'll start by saying that this question's very broad and shows very little original research, and that this answer shouldn't be seen as an encouragement of that type of question. Instead, this answer hopes to provide some extremely basic safety tips for folks just starting out with malware analysis.

Working under the assumption that you're running known, previously-researched malware, how you isolate your environment depends heavily upon what that malware is capable of. Some general rules that apply to most modern malware might be to:

  • Isolate your VM from the internet. This can be as simple as not setting up interface forwarding to the guest machine, and prevents the malware from communicating with any potential command-and-control nodes that might direct it to act unpredictably.

  • Use an appropriate hypervisor. There are a few major ones on the market, including VirtualBox, HyperV, QEMU, and macOS's Hypervisor.framework, to name a few; some of these are actively targeted by malware, and depending on the version, might be vulnerable to the malware breaking out of the guest machine.

  • Definitely don't install guest additions, or some other platform's analogue. The literal goal of this kind of software is to establish integration between the guest and host, effectively weakening separation between them. I'm not a malware researcher, but I'd be surprised if there wasn't malware that specifically targets this kind of surface.

To address some of your points directly:

How isolated can a virtual machine be made from the host?

At this point, a VM can be pretty thoroughly isolated, but some functions still have to go through the host more-or-less directly, with little hypervisor protection. Right off the bat, most non-KVM virtual machines (like VirtualBox) won't share a kernel with the host OS. This alone serves as a blocker against numerous exploit classes, most notably blocking the ability to run arbitrary syscalls against your host kernel (with the notable asterisk that a broken VM layer implementation can allow for malware to get around this in less obvious ways).

Your VM still has a process space within your host machine's hardware, though -- and while this isn't generally a risk because modern OSes provide decent process space isolation, it can still be used to exploit extremely low-level attacks like a rowhammer, where a process sequentially writes to memory in a specific way until it can read adjacent memory blocks that it doesn't own -- effectively allowing leakage of memory between processes.

Also worth noting that isolation tends to go away somewhat when you want to do essentially any kind of I/O: input and output necessarily mean passthrough, which exposes an attack surface which can be leveraged to perform host actions. This includes HID passthrough like a mouse and keyboard, as well as things like network passthrough -- although this is generally dependent on how well-implemented the I/O passthrough is implemented in your VM.

Should I (or can I?) set up a firewall between the guest and the host?

It depends, but it's generally not a bad idea. Most of the major platforms support hypervisor-level firewalls. These are at most as permissive as the firewall on your host machine, which is in turn at most as permissive as the firewall on your LAN or VLAN. If you want to leverage this instead of cutting off network access entirely by disconnecting the virtual network interfaces, I'd recommend doing research into which ports and hosts your selected malware targets and going from there.

Are guest add-ons a security risk?

Yes. They allow for all kinds of integrations between your host machine and guest machine, and don't always feature open specs where you can see what's being opened up; see above.

What about shared directories?

That depends on how you're doing it, but it's often a bad idea. Many hypervisors do this by creating a virtual drive mounted within the guest machine whose root is in that directory. Depending on the implementation of that mechanism, which can vary slightly between frameworks, you may or may not be safe, depending on what malware you're trying to test.


My concern is that you've performed very little research into this, and that you may end up harming your machine or your data. Before you continue, I'd advise you to look into the different isolation mechanisms on common OSes (KVMs, how they integrate with higher-level virtualization frameworks (), containers (), and the chroot mechanism () to name a few), when each is appropriate, and what they can and can't do. At that point, you'll be able to better judge whether or not you can safely play around with malware in an appropriately-isolated environment.

Finally, you shouldn't engage in trying to work with new or little-known malware (unless you're a seasoned security researcher, but this answer isn't aimed at seasoned security researchers). Malicious actors are extremely creative when it comes to what they exploit and how they exploit it. To get an idea of this, have a look at any recent DEFCON talks that aren't centered around social engineering or gaining physical access through mechanical means.

  • 3
    I don't think there is much difference in terms of isolation, in principle, between KVM and VirtualBox/VMWare/... as all of them require kernel module support and use hardware-assisted virtualization. Maybe you meant containers/dockers? That said arguably pure qemu exploits would only be in userspace but nowadays it has probably much less scrutiny than kvm (see also floppy drive exploit) but neither kvm nor qemu allows direct syscalls into kernel but both allow indirect (via virtualization or para-virtualization). – Maciej Piechotka Apr 5 '18 at 20:48
  • @MaciejPiechotka my mistake, that was misphrased. I've updated the answer, but thanks for bringing this up! – 0xdd Apr 6 '18 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.