Tor Browser 7.0.9 is released

by gk | November 3, 2017

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

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

November 03, 2017

Permalink

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

In addition to Whonix users, right?

Anonymous (not verified) said:

November 03, 2017

Permalink

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.

boklm

boklm said:

November 03, 2017

Permalink

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.

Anonymous (not verified) said:

November 03, 2017

Permalink

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.

Anonymous (not verified) said:

November 03, 2017

Permalink

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.

Anonymous (not verified) said:

November 07, 2017

Permalink

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
and
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 (2o7.net, .. 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.

arma

arma said:

November 03, 2017

Permalink

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:
https://www.wearesegment.com/research/tormoil-torbrowser-unspecified-cr…

Fabio Pietrosa… (not verified) said:

November 03, 2017

Permalink

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

Anonymous (not verified) said:

November 03, 2017

Permalink

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://ftp.badsite.com/file.txt")?

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 https://www.wearesegment.com/research/tormoil-torbrowser-unspecified-cr…, 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://)

bay1 (not verified) said:

November 04, 2017

Permalink

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.

Xanthippe Xero… (not verified) said:

November 05, 2017

Permalink

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.

Xanthippe Xero… (not verified) said:

November 09, 2017

Permalink

I got 7.0.5 as an automatic update on a previous Tor Browser version.

7.0.9 too, I used the in-browser update mechanism. Too bad 7.0.5 never warned me there was an update.

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.

yawning

yawning said:

November 05, 2017

Permalink

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?

gk

gk said:

November 07, 2017

Permalink

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.

Sgt. Jones (not verified) said:

November 05, 2017

Permalink

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:

-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJZiJH/AAoJENFIP6bDwHE24SEP+wZvI/cdZvctazPgS9vaUrXh
U9hMhPYKByMEsvCwqRZo8VlS3jVoJMUhaOfwpj/nVmUfxamrXXdt7OaAfS+MZV1f
bLuBCTE3UNLW87RqcxnC0muKrLQpx1Jbfet0h2YGL4qDo/QCN5YzJGbcLBOW5VgD
1tFGMSMcZY4yTGZz3MAvqdAxyTEfj/rkAYyukAPZ0RjwhTYYEgs7+xXbdpP/8yG8
NxEe83Yyxl81PK/3PD2lnecoyE5zRH/IlsPm0cakNuuecqhdKGk75ZVDuzoWTAjn
g1TzZ9HkPRFwU1O3imik7LWh7QvSxr1R37hyo7cCy75d83rM5xGAAR+6DFsp276X
LdXnVi4wxB5CNaHBq/tUS0E7SWJGBo1ZuVC/851VdtdWdy1eWs0zUyggywQzQ5tn
SGK3n8W6+2oz262/VD9glX7P20PNWG/RkALLE5XnA/9ZzRtcYYtrpGuKWyi7pDyd
ZABNZvS82dCMbWRFoKiUEzsEcHHx6S6ZZYnyVic7Pqqv5AAwpMbblbRKenmFwfJ7
+eCh4ZUWpLRb9ArRjUAFS3oOcj1BW9LQtG3aOsGR91pMu3oqwJebeT5a8p9ZjPkh
TXLIeu+VkLbIgn4y20fErVhsLPf/dMOEhOg61+SNlOnggxzrIE3ILarTZaXOKvwV
v3gd5gqahz3WmQrw1IRd
=PV7o
-----END PGP SIGNATURE-----

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

Richard (not verified) said:

November 06, 2017

Permalink

What if the user is under Tor using normal Firefox browser and Windows (I mean, not Tor Browser, just Mozilla Firefox properly set to use with Tor expert bundle)? Will he be vulnerable to this TorMoil bug? Or he is not vulnerable because OS is Windows?

Anonymous (not verified) said:

November 06, 2017

Permalink

Due to a Firefox bug in handling file:// URLs it is possible on both systems that users leak their IP address

Could you tell in which TBB version this bug first appeared?

There are some news about recent busts, where police was running one onion HS during 11 months. Later 95,000 IP addresses were discovered:

We have seen in several hidden forums that they recommend certain file-sharing services, and this discussion may happen not just on the Internet. One can therefore look at this world map as a representation of several geographic networks of downloaders

Can this 95,000 IP leak be related to this TBB bug? It is written that

The information is gathered from activities logged from a small number of file-sharing services which are preferred by people who share this kind of material.

However, if people are in "hidden" (tor) sites that rely on tor, all files are usually downloaded in the same browser that also uses tor. Is it meaningful that 95,000 people used their normal browser to download files faster without tor?

Anonymous (not verified) said:

November 07, 2017

Permalink

uBlock Origin
It looks like that if you use the uBlock Origin addon like the Tails version of Torbrowser does that "wss://" websockets are blocked.
Why does Torproject not embed the uBlock Origin addon as well in Torbrowser?

Anonymous (not verified) said:

November 08, 2017

Permalink

I see, I see also filter list functions in Noscript and https Everywhere (one big list but not covering many websites too), but not a special function in Noscript that protects the user from unwanted functionality in the browser like the ones discussed in this topic.
Therefor the ublock addon seemed to be a reasonable solution because it does block this, it is also used by TAILS and above all it seems that we cannot rely on the continuous changes that firefox has with functionality that no one really wants and is creating security and privacy problems for at least 3 years now. Mac users probably better can use TAILS because their support is far more broader and reliable then mozilla offers.
Thank you for answering anyway

BigBrother (not verified) said:

November 07, 2017

Permalink

Takes 7 mouse clicks to turn off automatic updates!! Even to change to "Check for updates, but let me choose whether to install them"

Also:
Edit > Preferences > Security > Warn me when sites try to install add-ons > Exceptions > Remove All Sites > Save Changes
is NOT respected when restarting!!!

Surely you can do better than this!!!!

Or is TorBrowser secretly spyware????

Anonymous (not verified) said:

November 12, 2017

Permalink

I'm unable to watch videos with the webm format, this the message I get next to the link "Your browser does not support HTML5 video". I have latest version of tor browser 7.0.9, any solutions?

Anonymous (not verified) said:

November 13, 2017

Permalink

So is this problem caused by file:// being handled in the context of the host, local address? We've been here before, similar to the problem with allowing unfettered local address access, in that it can bypass the proxy... only in the case of local address access the useful situation exists.

I don't see that when I am using the test. It tells me I am using a Mac but I actually tested with a Linux machine. And I did not see my locale either. So, whatever they report, they are not really recognizing your configuration.

Anonymous (not verified) said:

November 14, 2017

Permalink

2 questions: Is it expected that a transition to quantum-base would resolve the builtin file manager issues, and if that's the case,
Is there a trac somewhere for investigating a fix that does not involve gutting file:/// support? Which is to say if the current design has an issue with multi-process access to shared proxy is there a trac to start?

Where is the a… (not verified) said:

November 14, 2017

Permalink

7.0.10

Anonymous (not verified) said:

November 15, 2017

Permalink

Is this log regular?

13/11/2017 14:31:27.000 [WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (No route to host; NOROUTE; count 1; recommendation warn; host 79861CF8522FC637EF046F7688F5289E49D94576 at 171.25.193.131:443)
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus
13/11/2017 14:31:41.000 [NOTICE] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for some of our primary entry guards
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 64%: Loading relay descriptors
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 69%: Loading relay descriptors
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 76%: Loading relay descriptors
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 80%: Connecting to the Tor network
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit
13/11/2017 14:31:41.000 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
13/11/2017 14:31:41.000 [NOTICE] Bootstrapped 100%: Done