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.

(Log in to post comments)

Tor and browser vulnerabilities

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

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.