Re: How are hackers breaking Tor and trojan users?

[Arrakis <arrakistor@xxxxxxxxx>]

roger wrote:
> All of the Windows transparent proxying approaches I've seen so far come
> with a huge VM blob (plus the requirement of a huge opaque VM player),
> so while it would be great to offer it as one download option, it can't
> be our only option: there will always be folks with few resources for
> whom it isn't suitable.

I think about that a lot. We've got the current version of xB Browser
down to 10 MB. Now if we move to a VM solution you bumped it up to
a 30 MB download at least. Is the issue that the user can't download
that size? Is the issue that the user doesn't have the storage? Is
the issue that the user doesn't have the overhead to run a VM? If we
knew the user you had in mind a little better, that would help. We
have our own idea about who they are based on usage stats, but maybe
that is an after-the-fact metric.

I think the VM solution is possible to meet most of the criteria.
There is a new fork of xb machine/xb browser in the works that may be
hybrid solution.

> But the real problem here comes down to the lack of design documentation
> or security analysis on the current Windows transparent proxying
> options. Nobody knows what's in them really, nobody knows how to
> reproduce them so they can confirm what's in them, nobody knows how
> they're *supposed* to work so they can't verify that, there's no place
> to go to read a good analysis of the tradeoffs, etc. In that respect,
> we're still in the same place we were a year ago, when I wrote my previous
> mail on this topic:

This is a change I've been pushing for. The only problem is the drastic
evolution of the design. The tradeoff is naturally that we innovate faster
than we can write up a paper, getting those things done in parallel would
be amazing at least. First we solved a vm problem, then we toyed with
remote filesystem mounting, then we scrapped local userdata partition, and
now we're doing some other interesting things. We can get there faster
than we can talk about getting there, and unfortunately the "there" isn't
a place but a process. However, I think we're approaching a point where
we can say "yes, this design solves these problems, and treats these others
in this way" with some consistency. At that point, the paper can get framed.

> Just so we're all clear here, I believe Steve is referring to browser
> vulnerabilities that can force your browser to bypass its proxy
> configuration and skip over Tor entirely. Attacks like this do pop
> up periodically; I am stunned at how many bugs there are in Firefox,
> and IE is even worse.

Including but not limited to.

> This was a great attack, but I think the latest versions of Torbutton
> and Vidalia make it a non-issue going forward. I would love to hear if
> you think otherwise.

I think otherwise, but time will tell.

> But we have to also remember that the broader class of 0-day software
> vulnerabilities also includes ways to exploit your browser to compromise
> your computer, run programs on it, steal all your data, etc. And I think
> we all agree that end-to-end application vulnerabilities aren't going
> to get resolved just by sticking your Tor in a VM.

It's true. Local security has to be strong, which is something we've gotten
a good deal accomplished on in xb's vm. You would be hard pressed to find
a more locked-down system that runs tor. As for the aforementioned attack, it
isn't something I think is only tor's problem, but perhaps a bigger issue.
The point is, you can't just ignore it by writing it out of the threat model.
Or maybe you can? However, we can't just go ahead and spoil christmas for
everyone because you want to know what's in the box. I mean, after all, you've
written a design doc and security analysis. I'm sure the code just writes
itself at that point and you've got nothing to worry about. :D On a
serious note, I don't think it is something you're going to want or be
able to apply a patch to for a strong solution, so disclosing it privately
isn't going to be a concern. Just sit back and enjoy the magic.


Coderman, decimating as usual! You are entirely correct, but a little
perspective is great.

coderman wrote:
> this is a pretty strong statement and unsupported for any more complex
> attack against a host.  to claim immunity from 0day is to ignore the
> (less likely) use of multiple exploits against a virtual machine
> environment for escalation of compromise of the guest up to full
> control of the host. [0] [1] [2] [3] [4] [5] [6] [7] [8]

While it is theoretically possible, it becomes exponentially unlikely
as you keep requiring to exploit one vulnerability built upon another.
In this specific case, let's take the xb machine design that kyle is
working on. The real attack vector there is the applications that are
already installed, and more vaguely, the vm itself. However, once the
processes are locked down to a specific uid/permission level you can
keep them from talking to one another or intruding on the other's turf.
Not that it isn't possible, but you shrunk a hole from the size of a
door down to a keyhole.

> unfortunately, without fundamental and sweeping changes in the way
> software is designed, implemented and used the 0day is here to stay,
> no matter who you are...

Hackers are incredibly creative, and you're right, the human mind can't
conceive of the prefect security that another human mind can't defeat.
Undoubtedly they will out-create design docs and security analysis.
The upshot is now instead of defeating just local security, you've
also got to defeat local security and the virtual machine. (However,
assuming an 0-day against the vm was bad enough, you could be introducing
a new vector, but the likelihood is that you're much better off
using them both.)

If the data the attacker is wanting to manipulate is outside the VM
altogether, then the final exploit needed is going to have to be
a VM breakout/remote code execution. However, how we got to there
through the stop-gaps already in place is going to be an exceedingly
high hurdle and perhaps require one of these in your quiver:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0948

So what does that mean? The attacker needs:
1) Be able to defeat or bypass local security
2) Discover you're using a VM
3) Be able to breakout of VM

Thanks again coderman,
Steve