Tor Browser 7.0.9 is released

Note: Tor Browser 7.0.9 is a security bugfix release for macOS and Linux users only. Users on Windows are not affected and stay on Tor Browser 7.0.8.

Tor Browser 7.0.9 is now available for our macOS and Linux users from the Tor Browser Project page and also from our distribution directory.

This release features an important security update to Tor Browser for macOS and Linux users. Due to a Firefox bug in handling file:// URLs it is possible on both systems that users leak their IP address (note: as of Nov. 4, 2017, this link is non-public while Mozilla works on a fix for Firefox). Once an affected user navigates to a specially crafted URL the operating system may directly connect to the remote host, bypassing Tor Browser. Tails users and users of our sandboxed-tor-browser are unaffected, though.

The bug got reported to us on Thursday, October 26, by Filippo Cavallarin. We created a workaround with the help of Mozilla engineers on the next day which, alas, fixed the leak only partially. We developed an additional fix on Tuesday, October 31, plugging all known holes. We are not aware of this vulnerability being exploited in the wild. Thanks to everyone who helped during this process!

We are currently preparing updated macOS and Linux bundles for our alpha series which will be tentatively available on Monday, November 6. Meanwhile macOS and Linux users on that series are strongly encouraged to use the stable bundles or one of the above mentioned tools that are not affected by the underlying problem.
Update: Tor Browser 7.5a7 has now been released.

Known issues: The fix we deployed is just a workaround stopping the leak. As a result of that navigating file:// URLs in the browser might not work as expected anymore. In particular entering file:// URLs in the URL bar and clicking on resulting links is broken. Opening those in a new tab or new window does not work either. A workaround for those issues is dragging the link into the URL bar or on a tab instead. We track this follow-up regression in bug 24136.

Here is the full changelog since 7.0.8:

  • OS X
    • Bug 24052: Streamline handling of file:// resources
  • Linux
    • Bug 24052: Streamline handling of file:// resources

November 03, 2017


Tails users and users of our sandboxed-tor-browser are unaffected, though.

In addition to Whonix users, right?


November 03, 2017


Why until Monday for the alpha release? Does the patch not work when merged for it or it's that you didn't have the time to test whether it works?

This is a bit a not-the-best-thing-you-could-pull-up type of thing, only if alpha users read this blog could they even know in the first place that they should use the stable build before the Monday release to not be affected by a proxy disobedience bug.

Alpha users are ideally developers wanting to test the software and report bugs, or at least users that are fine with experiencing bugs like this. They ideally aren't regular people actually needing Tor's protections in a significant way.

That said, I'm also curious why alpha needs to wait.

The main reason is that the process for building, signing and publishing a new release takes time, and since the stable channel is what most people are using we prepared the stable release in priority and released it as soon as we could without waiting for the alpha to be ready.

I bet that on modern CPUs such as AMD's Ryzen/ThreadRipper and Intel's i7/i9 lineup building speed can be really minimal. So is the reason why the build is so slow is that you're using old hardware that isn't affected by Intel's Management Engine or AMD's Platform Security Processor to avoid compromise of the build machine? In that case you're absolutely right and I'll support your decision 100%!

Whatever the reason is for the delay, that isn't it. They (perhaps correctly) don't bother about that stuff. Builds are supposed to be byte-identical between machines anyway.

Even on fast hardware the build process takes a few hours. After we have a build that we could match on different machines, the signature process is quite complex and involves transferring around 9GB of files between different places which also takes time. Then we need to transfer all those files to the mirrors which also take several hours. And finally we need to write a blog post, update the website and carefully check that everything is right before enabling the update. So with the weekend we were not sure we would be able to do all that before Monday, but it's done now.


November 03, 2017


I support removing file:// support as much as possible. It is a dangerous attack surface and most end users do not use it. Web browser is for http:// + https://. If you want to browse file:// use a different tool.

Special case like upload and download should restrict to browser's folder. An attempt to read or write outside the folder should be denied.

I support removing file:// support as much as possible. It is a dangerous attack surface and most end users do not use it. Web browser is for http:// + https://. If you want to browse file:// use a different tool.

This is wrong, I use it for opening PDF files instead of using the pdf reader in my system who can leak my IP address. Please never make sweeping generalization until you have a good idea about the use cases of other people.

I second that.
I'm using file:// for a local page that allows me to interact with my server, tor hidden service,... over my local network but this update completely broke it.

See above in the blog post: "A workaround for those issues is dragging the link into the URL bar or on a tab instead." Just clicking on it does not work at the moment.

My problem has nothing to do with clicking on links, the workaround for that works perfectly fine.
What I'm talking about is the fact that when I open my local webpage using file:///path-to-local-webpage/index.html in the url bar I see errors in the console like
ReferenceError: $ is not defined
NetworkError: A network error occurred
The local webpage used to work like a charm without any warnings/errors in the console so this update is clearly breaking more than just links.

I suggest to remove the "file://" support and (!) in-browser pdf functionality from Torbrowser.

About a more than half a year ago, someone asked on this blog how safe the "file://" functionality was, answer; safe.
While it is not.
Your browser should not have this functionality because it is for browsing online and not for browsing on your computer.

Regarding pdf, we all know that pdf's are widely used for (malware) attacks, also in combination with webbugs. So it is a bad idea to use your browser for opening pdfs.
Especially when you realize that probably the most of Torbrowser users don't have the functionality enabled to use Torbrowser as their standard browser (and there you go, well actually the pdf-webbug).

Pdf reader leaking tricks? If you use the well known pdf reader from that company than also is the largest tracking company in the world (, .. anyone?) you should at least take some time to just look at the preferences of your program (actually you should do that with all the programs you use (!).
Disable any extra functionality that has to do with connecting to the internet and disable embedded script functions.

But probably better is to make sure that your firewall is configured well, do not white list the pdf readers (among many others, work with monitored whitelisting, etc.)
The best off course I can think of is to just own a Tails distribution, and use that when needed.

Unfortunately the mozilla bug is protected so we do not know how it works, which computer process was leaking the ip address?
Could it have been avoided when the process was not on the whitelist of your (extra) firewall config?

Using Torbrowser is a very nice standard protection in defence towards tracking companies, but if you really care about not giving away your ip address then it is probably essential to work with a firewall to prevent (all time populair) webbugs triggering other computer/program processes to connect with the internet directly. (Usual suspects, your Office program, your Pdf reader, your media player, your real standard browser (!)).
And off course to protect yourself from malware attacks, because most malware is not coming right away along as malware but usually need at least another step to fetch the real malware from the internet.
That process does probably not (always) succeed with a firewall blocking that new connection.

Torbrowser, very nice.
Extra firewall? Absolutely necessary to protect your safety and privacy (more).
Use at least Torbrowser + firewall program.
Use them both I should say.
And I hope that we get to know which extra computer process was activated to connect with the internet with this bug, so we can protect ourself and not being completely dependent on Torproject.

Second that!

TBB is my default Linux browser, and I had to stand on my head to make it so. I keep a lot of hypertext documentation on my local hard drive and view it with the default browser.

Among other things I display weather statistics from my own weather station. The *weewx* package creates *.html documents on my local hard drive on a schedule. I've had to switch to *iceweasel* to see them. These weather pages potentially contain links to other Web-based resources. I guess I'll just have to remember I'm not using a hardened browser while visiting those.

See above in the blog post: "A workaround for those issues is dragging the link into the URL bar or on a tab instead." Just clicking on it does not work at the moment.

Oh and what about your sweeping generalsomething? Last time I checked TB isn't a magic panacea. You like to use TB to look at PDF instead of sand-boxing that shit? How's that sane? You trust code written for public internet use (which has been re-purposed admirably for flexibility with tor network) to look at pdf (PDF!?) securely? If you cannot allocate some more memory to that crappy vm you run or sandbox a separate document reader process then you shouldn't criticize someone for giving a damn about TB's security.

Hasn't TB retained the ability to load local server addresses (with modification)? I haven't checked because I like to separate control. If so then why keep file:/// support at all, just a moving landmine.

I use Windows, unless I setup a VM (will use up a lot of RAM and I don't have many, thus degrading my user experience) - there's no simpler way than just using the Tor Browser.

Thanks again to Filippo Cavallarin for reporting this one to us!

I know that security researchers have a choice about where they can send their bug reports, and some of the huge evil corporations pay pretty well, so we should all applaud "We Are Segment" for choosing the path that makes the world a safer place, rather than a less safe place.

Here is a link to their page about it:…

Filippo and We Are Segment Team are also supporter of Italian Hackers Embassy events, fostering non commercial aggregation of Italian Hackers Communities! Kudos and thanks for all you are doing in such a nice way! -naif


November 03, 2017


Any one have an idea on how this might have been exploited? Was the vulnerability in how the URL was parsed (ex using a url like file://")?

It could be any number of things. Perhaps it involved interacting with some character device, which would explain why it affects Linux and OSX, but not Windows. Like the file URI parsing code is probably identical between Linux, OSX, and Windows versions of Firefox. The majority of the code is operating system agnostic, so the fact that it only affects *nix systems strongly narrows down the possibilities.

While I don't know for sure and can only speculate, my best guess is that it is related to the browser accessing a character device or something similar, since that's the only big difference between the behavior of their filesystem layouts. It wouldn't be a bug in the URL parsing code because the vast majority of code between Firefox for different operating systems is the same. I would be surprised if there were any significant difference between the Linux/OSX and Windows versions when it comes to file parsing.

first think about how local addresses can be exploited to leak in tor browser, they are blocked by default for a reason, and require your action to enable. second think about where files are located when invoking file:// urls and where the code which handles it is located.

from the wording it clearly impacts the local.file:// usage not when files are viewed on the server

so how to exploit? convince you to open a file://url to a local file (convince you to download it before), the file is formed to include remote assets possibly including identifiers to track back. when loaded via file:// local file runs local address and by default may not always obey proxy as local addresses tend to not traverse gateway.

not deliberate or malicious in design, but kind of like trying to compel adobe flash to obey proxy with jedi mind tricks

Actually, it can't be that. From…, it says this:

>Once an affected user navigates to a specially crafted web page, the operating system may directly connect to the remote host, bypassing Tor Browser.

This makes it pretty clear that it is an issue even without user interaction (such as opening something locally via file://)


November 04, 2017


i do not know & understand what is a 'specially crafted URL' : thx for the update (especially to the italian-team of course).
- still the same bugs (several last versions are affected) : your update interferes with no-script (before the update be done:downloaded:installed) on the old version - i suspect a manipulation related at blog tor (it is NOT a safe browsing & compromises my surf & login).
- still the same insecure settings : ssl/tls - i understand that an user -lambda- needs surfing everywhere & quickly without hassle but it does not suit me (it is NOT a safe browsing & compromises my surf & login).
conclusion : it becomes too much ambiguous : security vs anonymity / security OR anonymity

* Thanks again to Filippo Cavallarin.


November 05, 2017


Good thing local TV news reported about a new Tor Browser release, because version 7.0.5 (Linux, 32-bit) never warned me about any available updates. That's BAD.

You really don't have to worry about that when it comes to Tails. Let's go through each of the fingerprinting methods in turn, from the bleepingcomputer article in that blog post:

1) Screen Resolution - Tails will automatically start Tor Browser with a standard resolution. It even warns you if you try to resize the browser in a way that would give away your screen resolution.

2) Number of CPU Virtual Cores - If I remember correctly, Tor Browser blocks the hardwareConcurrency function. Even if it doesn't, this is a rather limited signature on its own.

3) AudioContext - Tor Browser has recently fixed this issue.

4) List of Fonts - This only allows distinguishing the broad class of operating system. For Tails, it merely tells someone that you are using Linux. Tails doesn't attempt to hide the fact that it is Tails, either, as their version of Tor Browser is unique to Tails (but still indistinguishable among different Tails users).

5) Line, Curve, and Anti-aliasing - This requires WebGL, which Tor Browser disables.

6) Vertex Shader - This requires WebGL, which Tor Browser disables.

7) Fragment Shader - This requires WebGL, which Tor Browser disables.

8) Transparency via Alpha Channel - This requires WebGL, which Tor Browser disables.

9) Installed Writing Scripts (Languages) - Tor Browser defaults to English to avoid this issue.

10) Modeling and Multiple Models - This requires WebGL, which Tor Browser disables.

11) Lighting and Shadow Mapping - This requires WebGL, which Tor Browser disables.

12) Camera - This requires WebGL, which Tor Browser disables.

13) Clipping Planes - This requires WebGL, which Tor Browser disables.

So, why did you make a big deal about supporting accessing Tor over AF_UNIX sockets, when you aren't ever going to leverage that functionality to prevent this sort of bug entirely?

Nobody said we'll never use that feature to do X. Moreover, *just* configuring Tor Browser to use AF_UNIX sockets would not have helped in this case. That proxy setting would have got bypassed, as well. So, there is more we would need and how to do that best for *all* OS X and Linux users still needs to get figured out it seems. I think that's important, don't get me wrong. But it's not done by just entering different proxy details into the browser settings.


November 05, 2017


Something not right. Tried to update, got warnings. Downloaded from website and it failed all time i downloaded the signature. Only Tor i could download not signature. I then copied the signature and got BAD SIGNATURE. Here it is:



Refreshed to new identity and then i got sig that returned good. A hostile exit node Why?