Tor Browser 6.0.7 is released

by gk | November 30, 2016

Tor Browser 6.0.7 is now available from the Tor Browser Project page and also from our distribution directory.

This release features an important security update to Firefox and contains, in addition to that, an update to NoScript (2.9.5.2).

The security flaw responsible for this urgent release is already actively exploited on Windows systems. Even though there is currently, to the best of our knowledge, no similar exploit for OS X or Linux users available the underlying bug affects those platforms as well. Thus we strongly recommend that all users apply the update to their Tor Browser immediately. A restart is required for it to take effect.

Tor Browser users who had set their security slider to "High" are believed to have been safe from this vulnerability.

We will have alpha and hardened Tor Browser updates out shortly. In the meantime, users of these series can mitigate the security flaw in at least two ways:

1) Set the security slider to "High" as this is preventing the exploit from working.
2) Switch to the stable series until updates for alpha and hardened are available, too.

Here is the full changelog since 6.0.6:

  • All Platforms
    • Update Firefox to 45.5.1esr
    • Update NoScript to 2.9.5.2

Update: We would like to remind everyone that we (The Tor Project) are having our 2016 fundraising campaign! Donate today!

Tags
tor browser
tbb
tbb-6.0

If you want to be sure just max out the slider AND set javascript.enabled=false in about:config. Just remember to set it back to =true if you ever lower the slider(which should be never). If you have javascript=false with the slider on low your browser will be easier to fingerprint (see https://panopticlick.eff.org/).

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

buen dia alguien aca habla español
hi good morning were speak spanish ?
mi inglish bery bad bery bery bad

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

thanks so much for rapidly releasing this update and communicating openly with users and the community about the situation!

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

I have an error on Debian Stable amd64 (updating from 6.0.6)

When starting up after update, after the message "Connected to the Tor Network", a dialog appears with a title "Software Update Failed" and text:
"The update could not be installed. Please make sure the are no other copies of Firefox running and then restart Firefox to try again."

After I click "OK" main window appears normally but the version is still 6.0.6.

I don't see any other Tor Browser instances running.

For unusual things: I have ublock-origin, request-policy-continued and flashgot from addons.mozilla.org, that's all.

I will investigate further.

The Firefox updater (which is what Tor Browser uses) gets super confused when I'm out of disk space. That might be a useful hint.

But yes, it also looks like you're running a bunch of extra extensions, so those are definitely worth considering more.

Let us know what you learn!

Hi arma, thanks for your suggestion. It looks like it was indeed lack of disk space (only ~60 MiB) that caused the problem. After freeing some space I tried again and this time it looked like the new version was installed correctly (previously the progress bar stopped at the beginning in the "Installing" window for some time and then I had the message I described before). However after installation/unpacking a new window appeared:
title: Software Update
header: Update Failed
text: The partial Update could not be applied. Tor Browser will try again by downloading a complete Update.

So the Updater tried to connect to the update server, but after a longer moment of no visible progress I decided to close the window and start the updater again. Unfortunately this time it didn't try to download update and there was no error message; it just started up normally and said it's version is 6.0.7.

I see I have "tor-browser-linux64-6.0.7_en-US.tar.xz" in "~/.cache/torbrowser/download/". Maybe I could unpack it over "./.local/share/torbrowser/tbb/x86_64/tor-browser_en-US" manually. But Tor Browser currently says I have 6.0.7 version so maybe there's no need to panic;)

The paths you list are unusual. Are you using some external program, like Micah Lee's "torbrowserlauncher" program? Else, why did you end up with files in those locations? Tor Browser should be keeping its fetched stuff inside its directories.

Yes, I'm using Tor Browser Launcher:
https://tracker.debian.org/pkg/torbrowser-launcher

Otherwise I'd would have to check the signatures myself the first time I download Tor Browser;)

So all what I've written so far maybe affects only Tor Browser Launcher because it looks like it intercepts the start of Tor Browser and performs updates itself. I must say I had a few problems in the past with this launcher and often the solution was to wait for a new version to appear in Debian's repo.

So what's the recommended way of using Tor Browser in Debian? Using this Launcher or downloading manually Tor Browser the first time (and checking signatures) and then Tor Browser will perform update itself and check sigs?

The recommended way is indeed to download Tor Browser once, check the signature, and then let it take care of itself after that.

Torbrowserlauncher is generally fine to use if you are excited to use it, but if it breaks, you get to keep both pieces. :)

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

So our enemy just could not wait for the clock to strike midnight....

Many thanks to the researchers who noticed the exploit being used in the wild to target our community, and to Mozilla and Tor Projects for your rapid response fixing the issue!

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

[Moderator: please do not censor this! I'd try to comment in the Tor Project HR blog, but no user comments are permitted there.]

Great news that TP is hiring a developer.

However, I with Shari or Roger would speak up and confirm that they are at least attempting to make it very difficult for CIA (or another TLA) to attempt to insert a mole inside Tor, as some fear happened in the Chasteen fiasco.

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

Does this effect the tor browser in tails too. Do i need to update tor in tails as well?

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

Could this exploit be used to extract anything from the non-Tor Firefox that the browser isn't already giving away?

As for setting the security slider high in Tor, doesn't everyone already do that? Doesn't seem much point using Tor if you don't.

Well, it depends what the payload of the exploit does. Early indications are that it collects your hostname and your mac address and then sends it to that IP address in France.

I think both of those pieces of information might not be straightforward to get through the legitimate browser APIs.

As for the security slider on high, alas that breaks many websites. Millions of people use Tor each day, and many of them expect "the web" to behave like it does in other browsers. We face a tough battle trying to convince websites to be not broken if you don't want to run the latest crazy web 4.0 fad, and it's getting worse as Chrome accelerates the race to the bottom.

I guess this comes back to "whatever you think Tor is for, I guarantee you there are people who use it for something entirely different than that."

Usually what I end up doing with the security slider is to try to visit a new website with the slider set to "high", and then gradually lower the slider and refresh the website if the previous setting renders the site unusable.
It is rather tedious though, and I can't remember on what settings which sites work, except for those I visit semi-frequently.
Either way, is this a correct approach to using the security slider?

I see lots of folks yelling one should never set it to anything other than "high". But that's just so ridiculously impractical. I can't for the life of me imagine how anyone would manage to use the web in such a way.

I set the security slider high permanently. Most sites work fine. If they don't, and I trust them, I simply allow the site in NoScript temporarily and then it works fine. Those few I encounter and the far more Cloudflare sites, I have taught myself to regard as saving time not bothering to look at them. For me, the web I want to see works with the slider set high all the time. YouTube doesn't work. But watching YouTube in Tor is both a waste of time and a bad habit, so I'm glad it doesn't work, it reminds me to do something more productive or just get off the computer and read a book. If I'm missing something on the web, I've forgotten what it is. If I'm encountering problems, they have become non-problems in usage. I feel this breeds a better approach to browsing so I thank Tor for it.

I think that's a great attitude and I hope things are good enough for it to be practical for everyone to share your attitude.

If anyone does come across a website that they feel such a strong need to read that they consider allowing javascript so they can submit to the CloudFlare captcha, a less bad option is using a proxy like https://archive.org/web/ https://ixquick.com https://startpage.com https://validator.w3.org or maybe even https://translate.google.com ... hopefully TBB will start detecting CloudFlare like captive portals are detected, and proxy it automatically, so new users aren't tricked into enabling javascript.
These proxies aren't to use instead of Tor but with it. For websites that block people with Tor from reading them (with the nonsense excuse that blocking read-only access prevents spam).

If you must watch a video, instead of enabling javascript just view-source and search for ".mp4"(on youtube you might have to look for an iframe first), or look for a website that lets you download youtube without javascript; there are plenty. Make sure all your media players and decoding libraries are up to date. Videos aren't as dangerous as javascript but ffmpeg and stagefright have been attacked before.

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

FFS, stop enabling javascript and downloading fonts/svg by default in firefox.

Don't pretending to take security seriously when the browser is wide open.

I appreciate your preference for security over usability, but how many times are we going to have to go over this? It's a tradeoff, and it's been explained in the Tor Project FAQ for a long time: https://www.torproject.org/docs/faq#TBBJavaScriptEnabled

If we disable JavaScript by default, the Tor network will shrink substantially (people will go back to Chrome or whatever) and make all fingerprinting/correlation/confirmation/timing attacks even easier than they already are.

There really needs to be a FAQ about this. It's because, as the name might suggest, the sha256-sums-unsigned-build.txt file, contains the hashes of the raw unsigned binaries, while the actual executables have Authenticode signatures.

So why do they make it so difficult for us to check the integrity of the downloads?

We are behind firewalls so using gnupgp and verify using public key is out of the question.

Who's the genius who decided to provide check sums nobody can use?

Why even bother providing hash for different files?

Why don't they just provide another set of hash so people can quickly verify the signed downloads?

Everyone and their dog provides hash for the files in the same directory, it's not rocket science.

What does the hash give you when it is downloaded from the same website as the binary? In other words: If you are concerned that you really got the binary we wanted you to get why can't an attacker give you a modified binary AND and an accordingly modified hash value?

The checksums have a different objective, see: https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerif…

Could you elaborate on why using GPG is out of the question if you are behind firewalls?

Yes, that has been a problem for a long time now. It works under torsocks now with no gpg.conf modifications (unless you want a .onion keyserver), for me at least.

It's also possible to get they key fingerprint from https://www.torproject.org/docs/signing-keys.html.en and download the key from pgp.mit.edu, and paste it into gpg --import. It's a few steps more than it should be, but you only have to do it once every few years (whenever the signing key is replaced).

I realize I'm not answering the original question about the hashes anymore, but it is important to understand the difference between a hash and a signature, and which threats the former doesn't protect against.

Some people download the same files 10 times from 10 different exit nodes, then verify the hash for all 10 of them.

This doesn't protect against the tor project source website being hacked and files replaced on the server, but can protect against man in the middle switching the files with infected ones.

Unless the hacker hacked all 10 exit nodes and circuits.

May be he just wanted to know if he downloaded the complete files, not missing 10 bytes at the end.

The tor browser download site doesn't exactly show the complete byte count of each files.

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

WTF is gfx.downloadable_fonts.enabled set to true?
We were hit by the font vulnerability before already, do you people ever learn?

gk

gk said:

December 01, 2016

Permalink

I guess you are mixing some things up? The vulnerabilities you have in mind were probably the ones related to the Graphite font rendering library. This one got disabled in Firefox 38.7.1esr and still stays so, see your gfx.font_rendering.graphite.enabled preference which is set to "false" in Tor Browser.

Mateus

Anonymous (not verified) said:

December 01, 2016

Permalink

As a web designer I actively try to convince others to stop using fonts as icons and UI elements, but so far I feel very unsuccessful. Many websites are totally unusable without fonts.

ps: Sometimes if I don't want to enable fonts, I just open up Inspector and navigate using that. Not too user friendly though.

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

Why isn't "Tor Browser 6.0.7 is released" on the front page of torproject.org yet?

It has been hours.

Don't tell me the index page only get updated like once a day

You mean in the Recent Blog Posts section or on the website in general? If the former, good question but it is not the only blog post not showing up. There might be an underlying technical issue. If the latter, because we don't advertise new releases on the landing page.

Wow this is so stupid:

Changed 10 months ago by Sebastian

Resolution set to worksforme
Status changed from new to closed

The blog feed on the front page is updated once daily, so it's expected that blog posts won't make it there immediately

Mateus

Anonymous (not verified) said:

November 30, 2016

Permalink

*** 6.0.7 CRASH REPORT***
The last vulnerability was caused svg
So I updated TorBrowser to 6.0.7
went to about:config and set everything svg to false
when I restart the TorBrowser, it crashes after Tor connects.

I've nailed the crash down to one single setting:
setting "svg.display-lists.painting.enabled" to false

How to reproduce crash:
in about:config
set svg.display-lists.painting.enabled to false
restart tor browser
it'll crash after tor is connected

The browser itself is using SVG for non-content parts so I guess disabling the preference you mentioned is not working well with those parts. This seems to be a Firefox bug to me and I bet Mozilla developers would gladly look into it (you can file a bug at https://bugzilla.mozilla.org).

That said if you want to disable SVG used in websites you should set the security slider to "High". That's enough.