Re: More Secure Tor Browsing Through A Virtual Machine in Ubuntu

[7v5w7go9ub0o <7v5w7go9ub0o@xxxxxxxxx>]

Kyle Williams wrote:
> On Mon, Aug 24, 2009 at 6:18 AM, 7v5w7go9ub0o 
> <7v5w7go9ub0o@xxxxxxxxx>wrote:
> 

==

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

My initial presumption on this question is to approach desktop use as
one does chroot jails:

- use X clients to provide desktop windowed use of X-applications
on the VMs (e.g. Firefox/TB/etc.)

- use SSH to transfer data, and if necessary, root up to manipulate
stuff within the VMs. Alternatively, maintain the VMs separately, and
copy the "virgin" VM into memory where they are started (this is how I
run my chroot jails).

(I suppose one could use VNC/SSH)

either way, one would have some very restrictive firewalls/packet filters.

Presuming that the above applies to any VM application, do you know if
any of the current crop are most breakout proof? If that hasn't been
determined (by the folks who track vulnerabilities - e.g. securityfocus,
sans, etc.), is there a variety of VM that is known to be weak?


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

Nah...... I'd keep them separate, and communicate through networking -
likely X and SSH.


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

understood; agreed.


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

I'd assume that the host/or/primary OS would SSH into a guest, using an
unprivileged account, and simply copy/move files via ssh. The SSH client
on the host/primary could be easily jailed; the connection could be
generally kept open.

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

(like this? <http://opensource.dyc.edu/tinhat>  (p.s. IIRC, it is
encrypted with loop-aes))

What I'm getting at in this question is the ability of root to gain
information about the host - ideally the VM doesn't know anything about
the host, or the real world in which the host/hypervisor is running.

IIRC QEMU created a hardware emulation layer, in which you could tell
the guest OS all sorts of lies :-)

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

Here is where I'd *guess* that a hypervisor would be the way to go - I
haven't looked into it

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

Moka5 appears to be a VNC client within a VM client.

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

Using X, I right-click:copy the email link in the mail client Jail/VM,
and then middle click the browser that is in the "browser" Jail/VM.

> Should B-VM and E-VM even be able to know about each other?

On my box, they don't (B-jail and E-jail).

I looked into this once, and IIRC there is a configuration setup using X
that would transfer TB http selection actions to FF via the window; but
I'm lazy and I don't mind pasting links.

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

You just summarized what I attempted to describe above.
> 
> 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?

A single instance - it would make timing attacks more difficult.


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

Don't know how they'd do that without access to the control port.

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

The only access to the control port, IMHO, would come from the
primary/host. TBH, I don't use the control port for anything, other than
infrequently bringing up vidallia - then it is curiosity


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

Thanks for the thoughtful response.

Are there any other newsgroups or webgroups that are focused on VMs, and
that might have some heavy-duty insight into all of this?