Tor and browser vulnerabilities
| Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net. |
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:
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:
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 |
(Log in to post comments)
Tor and browser vulnerabilities
Posted Aug 7, 2013 20:43 UTC (Wed) by jmm (subscriber, #34596) [Link]
Tor and browser vulnerabilities
Posted Aug 7, 2013 21:59 UTC (Wed) by dw (subscriber, #12017) [Link]
Tor and browser vulnerabilities
Posted Aug 7, 2013 23:03 UTC (Wed) by yann.morin.1998 (subscriber, #54333) [Link]
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]
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]
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]
Tor and browser vulnerabilities
Posted Aug 8, 2013 13:01 UTC (Thu) by paulj (subscriber, #341) [Link]
Stupidity always wins
Posted Aug 10, 2013 23:55 UTC (Sat) by jmorris42 (guest, #2203) [Link]
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]
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]
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]
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]
