Is it possible to prepare an .ova file for Oracle Virtualbox that will access NAT network when is set to use Whonix? There are preconfigured virtual machines like Windows to use in Whonix, but are they safe to import?

I wonder because there is a suspicious project published by someone in Tor community (if anyone is interested i can send a link to download). Guest Additions are also used by this VM.

  • ova may contain a baby ;-) (kidding) – Anon Dec 15 '17 at 15:36

Whether or not it contains an exploit, specifically, is irrelevant in the broader question of whether an OVA file can be malicious. The answer to the broader question is yes, absolutely.

The Open Virtualization Format specification gives you an idea of some of the potential vectors, but the obvious one is that it could map your entire OS disk to the VM and then, on VM boot, run code that exfiltrates it via the network or modifies files on disk to elevate privileges or drop malware (it doesn't have to adhere to your OS's security controls around filesystem access at that point). The VM could also map arbitrary USB devices to the VM (including inserted USB sticks) and use them however it likes.

If we want to go into more complex attack mechanisms, the VM could utilise platform vulnerabilities in the CPU, PCH, or memory (e.g. recent vPro/AMT bugs, or rowhammer) to effectively escape the VM environment and run arbitrary code on the host.

You absolutely should not run untrusted OVF VMs.

  • At least VirtualBox first needs permission to access devices directly, doesn't it? I had trouble in the past getting it to work on purpose with a Linux host – Xen2050 Dec 14 '17 at 20:19
  • @Xen2050 The virtualised storage driver is loaded at boot, so it shouldn't technically require admin privileges but it may do in practice for other reasons. Also note that VirtualBox is just one platform that can load OVF spec VMs. – Polynomial Dec 14 '17 at 21:07
  • 4
    +1 for highlighting the difference between malicious code and exploit code. – forest Dec 15 '17 at 1:00

Any file can contain an exploit.

Whether it works or not, or if it requires a loader, is another story.

For example, if there's a buffer overflow vulnerability in the processing of .ova files, then yes, it could contain an exploitable vulnerability.

It all depends on whether or not you have a vulnerable application which processes the file that contains an exploit.

  • 3
    Excellent point, but I think the question was more about the specific dangers of running OVA/F VMs from unknown (or at least untrusted) sources... – A C Dec 14 '17 at 22:21
  • 1
    Agreed, that is why I upvoted the others. :) They are better answers. – Mark Buffalo Dec 14 '17 at 22:25

Yes, any guest OS such as contained in OVA files can carry malicious code; even mere data files of a certain complexity can effectively launch exploits.

Therefore, the flavor of Whonix you may be looking for is the one that runs under the Qubes OS hypervisor, as every aspect of Qubes is designed to prevent privilege escalation attacks from within guest VMs. In fact, the creators assume that guest compromise is likely and that a reasonably secure OS should protect the rest of the system in that case.

Note the long list of Qubes security advantages listed at the Whonix website.

Conversely, VirtualBox is a much less stringent VM environment designed mainly for administrator convenience, as the second bullet at the link explains.

This is not to claim that Qubes is impervious in any situation, but for most scenarios it raises the bar considerably. Since your goal appears to be preventing code of questionable intent from escaping or leaking in any way from a Tor tunnel, then its probably your best option.

The main downside to Qubes, besides loss of GPU access, is how finicky it is about hardware. It needs advanced CPU features such as IOMMU, SLAT, EPT and a BIOS that configures them exactly right. The Qubes HCL exists as a hardware guide.

Converting your OVA file for use as a Qubes HVM:

First, download the OVA to an AppVM then:

tar xvf filename.ova
# ...produces a .vmdk disk image
qemu-img convert -f vmdk filename-disk1.vmdk -O raw filename.img
# ...produces a flat disk image

Next, create an HVM in Qubes (here called 'mynewHVM'), then in dom0:

qvm-run -p myappvm 'cat /home/user/filename.img' >filename.img
# ...transfer img from appVM to dom0
mv filename.img /var/lib/qubes/appvms/mynewHVM/root.img
# ...for Qubes 3.x

From there you can access the HVM's settings panel and change Network to sys-whonix.

Finally, if your disk image contains a Windows OS, see these tips.

  • Edited to make conversion a two-part process for better security (tar/ova parsing carries risk). – tasket Dec 18 '17 at 17:27

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.