More Secure Tor Browsing Through A Virtual Machine in Ubuntu

[Kyle Williams]

On Mon, Aug 24, 2009 at 6:18 AM, 7v5w7go9ub0o <7v5w7go9ub0o at gmail.com>wrote:

> But ISTM that small, optimized, hardened little VMs would be ideal -
> additionally protecting anonymity; perhaps reasonably allowing the use
> of JS on your browser within your browser VM.
>

Agreed.


>
>
> Your post begs the questions:
>
> 1. Which VM software are the most breakout proof, should an attacker
> gain access with a root shell?
>

This is a tricky question which depends on your requirements.  Before I get
into which is better than which VM engine, I first must understand what it
is I want to do with my browser.
Do I want to be able to download data and save it, or just be able to
observe it?
If you want to save data, where/how do I store it in such a way that I can
securely access it from other mini VMs without compromising that
VMs integrity?

Older vulnerabilities exist for both VMware and Qemu that allowed access to
the host OS through the guest OS because the VM engine itself was "folder
sharing" from the host to the guest OS.
These have been patched for quite some time, but such a feature that allows
"guest to host" sharing makes me nervous, and I think should be avoided *at
the VM engine level* at all cost.
The downside is, I'm not sure how to save my downloads from the VM to
another VM or the host OS itself without opening up a whole for an attacker
to get through assuming a root compromise inside the VM.


> 2. Which VMs' guest software are the most opaque - i.e. have NO
> information available to a roving root?
>

I'm a fan of having a base ISO and storing any changes made in memory.  If I
do get infected by some 0day, the only information they could pull would be
any existing cookies, cache, or history I may have from my browser
(depending on my browser's settings).  Not to mention, since it's a read
only ISO, no permanent changes can be made.


>
> 3. Which VMs require the least overhead?
>

VMware fails right there.  The installer is 175+ MB compressed, and the
software is not portable (literally or legally).

I've been a fan of Qemu the last few years.  It's open, portable, small foot
print and low on memory usage.
With Qemu, I was able to create a Linux OS in ISO format that contained a
Win32 version of Qemu , Autorun.ini, and a win32 batch script that would
launch Qemu (in Windows) using the CD-ROM drive as the Boot device, and it
worked great.  This enabled both a both bootable CD and a Windows supported
VM all from the CD-ROM.  You wouldn't be able to do that with VMware based
on the size of the engine and it's dependencies, it would take up almost the
whole CD.


> 4. IIUC, one can attach a VM to his existing OS, or one can first
> install some sort of hypervisor followed by a primary OS, and a series
> of secondary OS's? If this is true, what are the pros and cons of either
> approach. (I presume that you want a number of VMs - each containing
> sensitive or vulnerable applications)
>
>
Take a look at Moka5(.com).  This is pretty much what we were aiming to do
at one point.
Moka5 is however based on (funded by) VMware , and vmware totally jacked
this idea from two guys after sending them a siest and desist letter
first....errr.

Back to the hypervisor; this would be really nice.  I have see some problems
though.

If I have a browser VM (B-VM), and a email VM (E-VM), how does the B-VM
communicate with E-VM through things like the "e-mail:" URI type?
Should B-VM and E-VM even be able to know about each other?
Perhaps having a virtual "clipboard" that supports copy and paste functions
between VM's, or does that open another security hole?
( http://www.securiteam.com/securitynews/5GP021FKKO.html )

To bring up another point, do all them VMs you want to be anonymous use the
same instance of Tor, perhaps running in it's own VM, or do they use their
own instances of Tor?
Lets say my E-VM is set to check my e-mail every X minutes. Does my E-VM use
the same circuit as my B-VM is current using?
So what happens if an attacker puts the client into a .exit loop, keeping
them stuck on their exit node (is this still a problem..?)?

I think this gets deeper in the sense of how much an application that uses
Tor can control Tor *without access to the control port*.  In this case,
having the .exit notation enabled would probably be bad if two or more
applications / VM's are sharing the same instance of Tor, as one infected VM
could affect the traffic on the other VMs.  There are lots of tricky
security issues that need to be taken into account when working on multiple
VM systems, or worse, VM to host OS solutions.

Well, that's pretty much what I've been thinking about for quite some time
now.  I've spent a ton of time looking into this and discussing it with
coderman.
It takes soooo much time to do all this, and it can become a bit mind
numbing if you do it for too long.

In my opinion, good security for your anonymity and privacy is a bitch in a
Web 2.0 world. It seems like all of our browsers, media players, IM clients,
and games are now being integrated to communicate with each other.  While
this seems great to the user's experience, it can be very destructive to
one's privacy and anonymity.


- Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20090824/d237bbe4/attachment.htm>