Tor and browser vulnerabilities [LWN.net]

By Jonathan Corbet
August 7, 2013

Tor is a project intended to make anonymous network browsing globally available. By encrypting connections and routing them through a random set of intermediary machines, Tor hopes to hide the identity and location of users from anybody who might be attempting to spy on their activities. One can only imagine that recent revelations about the scope of governmental data collection will have increased the level of interest in tools like Tor. So the recent news of a compromise of the Tor system with the potential to identify users is certain to have worried a number of people; it also raises some interesting questions about how projects like Tor should deal with security issues.

What happened

The Tor hidden service protocol allows services to be offered anonymously through the Tor network. Many of these services, it seems, are concentrated on servers hosted by a company called Freedom Hosting. They vary from well-known services like Tor Mail to, evidently, a wide range of services that most of us would rather not know about at all. The alleged nature of some of those services was recently emphasized when Eric Eoin Marques, the alleged owner of Freedom Hosting, was arrested on child pornography charges.

About the same time, users of various hidden services started reporting that those services were sending a malicious JavaScript program to their browsers. This program exploited a vulnerability in the Firefox browser to gather information about the identity of the user and send it off to an IP address that, it has been claimed, is currently assigned to the US National Security Agency (though some backpedaling is happening with regard to that claim). The exploit does not appear to have been used for any other purpose, but what was done is enough: Tor users hit by this code may have lost the anonymity that they were using Tor to obtain in the first place.

Who are those users? The hostile code was designed specifically for users running the Tor Browser Bundle (TBB) on Windows systems. TBB is based on the Firefox Extended Support Release with a number of security and anonymity features added on top. Anybody using Tor in a different configuration — or who was using a current version of TBB — will not be vulnerable to this particular attack. Linux users, perhaps on a system like Tails, were not targeted, but there is probably no inherent reason why an exploit for Linux systems would not have worked.

The specific vulnerability exploited by this attack is MFSA-2013-53, otherwise known as CVE-2013-1690. This vulnerability was patched in Firefox ESR 17.0.7, released on June 25, 2013. The Tor project incorporated this update and released new TBB versions one day later. So anybody who updated their TBB installation in the time between June 26 and when the exploit was launched will never have been vulnerable. Those who didn't get around to updating found themselves in a rather less comfortable position.

What should Tor change?

Needless to say, Tor users have been shaken by this series of events and would very much like to avoid seeing a repeat in the future. So there has been a fair amount of discussion regarding TBB and how the Tor project responds to vulnerabilities. But it is not at all clear that massive improvements are possible.

One possibility is to reduce the attack surface of the browser by disabling JavaScript; taking away the ability to execute code in the browser's address space would make a lot of attacks impractical. TBB does ship with the invaluable NoScript extension, but, as any NoScript user quickly discovers, turning off JavaScript breaks a lot of web sites. One does not know anger until one discovers, at the end of filling in a long web form, that the "submit" button runs a JavaScript snippet (usually for some relatively useless purpose) and the form cannot be submitted. So, in the interest of having TBB actually be usable, recent versions of TBB ship with NoScript configured to allow JavaScript on all sites.

There is a project in the works to equip TBB with a "security slider" that would allow users to select the balance between security and usability. But that feature is not yet ready for release; in the meantime, TBB users may want to consider enabling NoScript on their own. But, as the Tor project pointed out in its August 5 advisory, disabling JavaScript is far from a complete solution:

And finally, be aware that many other vectors remain for vulnerabilities in Firefox. JavaScript is one big vector for attack, but many other big vectors exist, like css, svg, xml, the renderer, etc.

There has been a certain amount of complaining that the Tor project silently fixed the vulnerability in June when it should have been making sure that users knew about the scale of the problem. Some users have gone so far as to state that TBB is a forked version of Firefox and, as such, it should be issuing its own security advisories.

The problem with this idea, of course, is that the Tor project is not really in a position to understand all of the many fixes applied by the Firefox developers. Even then, it is not always clear at the outset — even to Firefox developers — that a specific bug is exploitable. As Tor developer Jacob Appelbaum put it, the project just does not have the resources to duplicate the advisories that Mozilla is already issuing when it releases a browser update:

We're understaffed, so we tend to pick the few things we might accomplish and writing such advisory emails is weird unless there is an exceptional event. Firefox bugs and corresponding updates are not exceptional events.

Experience quickly shows that security advisories are also far from being exceptional events; more advisories would not necessarily convince that many more users to upgrade their TBB installations. TBB already checks to see if it is out of date and informs the user if an upgrade is available; there is talk of making that notification stronger, especially as the time since the update was released increases. Automatic updates were also discussed, but there seems to be little interest in taking that path; there seems to be some fear that the update mechanism itself could be targeted by attackers.

In the end, there are a couple of straightforward conclusions that can be drawn, starting with the fact that there may not be a whole lot the Tor project can do to avoid a repeat of this type of attack. The simple truth seems to be that we, as a community, have neither the resources nor the skills to properly defend ourselves against attackers who have the resources of national governments behind them. Software as complex as a browser is always going to have vulnerabilities in it, even if its developers are not constantly adding new features. Providing software of that complexity that is sufficiently secure that people can depend on it even when their lives are at stake is one of the great challenges of our time; so far, we have not found the answer.

Index entries for this article
Security	Anonymity
Security	Internet/Tor
Security	Web browsers

to post comments

Tor and browser vulnerabilities

Posted Aug 7, 2013 20:43 UTC (Wed) by jmm (subscriber, #34596) [Link] (1 responses)

It would certainly be best if the addons from TBB were merged into Firefox mainline: https://twitter.com/BrendanEich/status/364265592112414720

Tor and browser vulnerabilities

Posted Aug 7, 2013 21:59 UTC (Wed) by dw (subscriber, #12017) [Link]

Now there's a browser war Google couldn't even compete in. Yes please Mr. Eich, go right ahead and merge a Tor client into Firefox.

Tor and browser vulnerabilities

Posted Aug 7, 2013 23:03 UTC (Wed) by yann.morin.1998 (guest, #54333) [Link] (1 responses)

> a compromise of the Tor system

This is a bit misleading to me. As far as I understand the issue, the Tor network itself was not compromised. What was compromised is the browser.

The compromise of the browser could have well happened to a non-Tor user with the same browser, visiting a compromised website.

The Tor infrastructure is not impacted by *this* attack.

Regards,
Yann E. MORIN.

Tor and browser vulnerabilities

Posted Aug 8, 2013 8:36 UTC (Thu) by njwhite (guest, #51848) [Link]

> As far as I understand the issue, the Tor network itself was not compromised. What was compromised is the browser.

You're correct, though I don't think it's particularly misleading. The exploit targetted Tor's browser, and sought specifically to get around the anonymity provided by Tor by revealing the users' MAC and IP addresses. So while the core Tor infrastructure was not compromised, the anonymity it provides was compromised for some users. It makes sense that if you wanted to attack anonymity of tor users, the browser is likely to be a much weaker point than the tor network itself.

Tor and browser vulnerabilities

Posted Aug 8, 2013 11:16 UTC (Thu) by malor (guest, #2973) [Link] (1 responses)

It seems to me that depending on Tor alone has now been shown to be inadequate. At the very least, I'd suggest now running it in a VM, firewalled to be able to talk only to your Tor ingress node or nodes of choice, preferably with the virtual disks set non-persistent mode except when you want to update things. That way, if your browser is compromised, it's hard to immediately de-anonymize you. As the VM can communicate only over Tor, the attacker would have to download a binary over that slow network, and then use that binary to crack the VM interface and compromise the host, at least enough to override the firewalling. (you wouldn't want to run the firewall code on the VM itself, as that's too easily subverted.) This is at least an order of magnitude harder than just subverting the browser, and having it rat you out. And they have to succeed in the attack before you shut the VM down, as the non-persistent disks will simply discard their foothold on virtual poweroff.

It would be even safer to use a small dedicated Linux machine, on a separate LAN segment, with no access to the firewall/router it's talking to. You'd want rules to let it update itself, allowing it only to open specific ports to specific distro servers, and refusing all other traffic except Tor to specific machines. (You wouldn't, though, have the advantage of nonpersistent disks; you could still run a VM for that, if you wanted, though perhaps that level of paranoia is getting stupid.)

You need to be careful about DNS traffic. A single DNS query escaping your Tor network can give you away. I'd suggest blocking it completely, and then listing your Tor ingress nodes and distro update servers by IP, rather than name. Basically, you want zero undefined outbound connections allowed. No DHCP, no DNS, no NTP, no nothing. Allow only specific ports to specific servers, and just a few, and nothing inbound at all.

A small Atom server with two onboard LAN ports, and two more on a PCIe card, can make a *dynamite* little firewall, and will give you enough ports to have three separate internal networks of varying trust levels. You could dedicate one to 'machines I don't trust', which should include your Tor installation, and block them entirely from talking to machines you DO trust. And you can have a separate segment for machines offering services to the outside world, aka "the DMZ".

Not advice I'd give to the general public, since there's a massive learning curve involved, but I bet most of this crowd could handle it, easy.

FWBuilder, by the way, is a good tool for managing that kind of complex environment; when you're dealing with multiple private network segments with different trust levels, a visual GUI can help a fair bit with visualizing what's going on.

But then, of course, you're trusting that the FWBuilder program is generating the rules you think it is. If you're _really_ paranoid, you should write your ruleset by hand.

Tor and browser vulnerabilities

Posted Aug 8, 2013 19:06 UTC (Thu) by wtanksleyjr (subscriber, #74601) [Link]

That's a good point, I think. Your architecture looks very much like that provided by http://qubes-os.org/, so perhaps there's someone working on a similar project.

Tor and browser vulnerabilities

Posted Aug 8, 2013 13:01 UTC (Thu) by paulj (subscriber, #341) [Link]

The timing of the issue of the warrant for Marques' arrest is amazingly co-incidental, if that arrest was not a consequence of this exploit. Which is strong circumstantial evidence that this Tor de-anonymisation exploit was made and/or deployed by the US government.

Stupidity always wins

Posted Aug 10, 2013 23:55 UTC (Sat) by jmorris42 (guest, #2203) [Link]

If you are so paranoid you are using Tor (right or wrong, depending on what you are doing... you may be rational to fear) Why wouldn't you stick to sites that don't require Javascript or any other plugin? Heck, stick to sites you can use Lynx/Elinks on. Same for people hosting servers intended for Tor users, build assuming people want privacy. Keep it simple, keep it safe.

But no, we get people installing Tor and assuming now they are perfectly safe and using the same broken Internet tech, expecting a different result because the prinkled magic dust on it. Seriously? Windows and a buggy 'full' browser like Firefox was just a matter of time.

Have to second the views already expressed though about VMs, that is probably the way forward. Build Tor to run on the real OS and the VM can only see Tor. Let it break loose all it wants, still shouldn't get very far unless they can subvert the VM. Instead of a few Tor devels you have the entire hosting industry and VM interests working to detect and prevent that.

Tor and browser vulnerabilities

Posted Aug 12, 2013 9:04 UTC (Mon) by mjthayer (guest, #39183) [Link] (1 responses)

> TBB does ship with the invaluable NoScript extension, but, as any NoScript user quickly discovers, turning off JavaScript breaks a lot of web sites. One does not know anger until one discovers, at the end of filling in a long web form, that the "submit" button runs a JavaScript snippet (usually for some relatively useless purpose) and the form cannot be submitted.

I'm surprised that NoScript doesn't have an "ask" option so that the user can decide on the fly whether to execute a script.

Tor and browser vulnerabilities

Posted Aug 19, 2013 3:05 UTC (Mon) by steffen780 (guest, #68142) [Link]

That is so impractical it's not even funny ;)
Do you really want to click yes/no up to 10 or 20 times per site? And that's just counting domains - not individual scripts. Default block, then whitelist what you want, is the only really sane approach. Though NS is not limited to JS blocking so other methods (like default permit and blacklist facebook/google analytics etc) will still give some extra security, but asking every time would just make you throw the computer out of the nearest window...

Tor and browser vulnerabilities

Posted Sep 10, 2013 7:02 UTC (Tue) by glaesera (guest, #91429) [Link] (1 responses)

Some recent scientific research showed that TOR can only provide anonymity for a maximum time of six months, when used regularly.
I would like to point out, that it does not make any sense at all to use this without an online-tracking blocker.
Is this shipped with the TOR-bundle ?
There is also the possibility to identify users by their surfing-behaviour, this might even work without any cookies set, when they reappear regularly and for a long enough time at certain sites.
So at this time unfortunately online-anonymity is mostly illusionary and using TOR is pretty much like checking the 'do not track'-box in your browser-configuration, you only communicate your wish, but there is no warranty, that service-providers really comply to this.

Tor and browser vulnerabilities

Posted Sep 10, 2013 8:14 UTC (Tue) by glaesera (guest, #91429) [Link]

http://www.ohmygodel.com/publications/usersrouted-ccs13.pdf