Tor Browser 6.0.5 is released

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

This release features important security updates to Firefox including the recently disclosed extension update vulnerability. All users should upgrade as soon as possible.

That vulnerability allows an attacker who is able to obtain a valid certificate for addons.mozilla.org to impersonate Mozilla's servers and to deliver a malicious extension update, e.g. for NoScript. This could lead to arbitrary code execution. Moreover, other built-in certificate pinnings are affected as well. Obtaining such a certificate is not an easy task, but it's within reach of powerful adversaries (e.g. nation states).

Thanks to everyone who helped investigating this bug and getting a bugfix release out as fast as possible.

We are currently building the alpha and hardened bundles (6.5a3 and 6.5a3-hardened) that will contain the fix for alpha/hardened channel users. We expect them to get released at the beginning of next week. Until then users are strongly encouraged to use Tor Browser 6.0.5.

Apart from fixing Firefox vulnerabilities this release comes with a new Tor stable version (0.2.8.7), an updated HTTPS-Everywhere (5.2.4), and fixes minor bugs.

Here is the full changelog since Tor Browser 6.0.4:

  • All Platforms
    • Update Firefox to 45.4.0esr
    • Update Tor to 0.2.8.7
    • Update Torbutton to 1.9.5.7
      • Bug 19995: Clear site security settings during New Identity
      • Bug 19906: "Maximizing Tor Browser" Notification can exist multiple times
    • Update HTTPS-Everywhere to 5.2.4
    • Bug 20092: Rotate ports for default obfs4 bridges
    • Bug 20040: Add update support for unpacked HTTPS Everywhere
  • Windows
    • Bug 19725: Remove old updater files left on disk after upgrade to 6.x
  • Linux
    • Bug 19725: Remove old updater files left on disk after upgrade to 6.x
  • Android
    • Bug 19706: Store browser data in the app home directory
  • Build system
    • All platforms
      • Upgrade Go to 1.4.3
Anonymous

September 16, 2016

Permalink

Downloaded TorBrowser-6.0.5-osx64_en-US.dmg sha256
d79e18d691a407c9cc06ec508701bff2283d73b65d4321e254763b17d0a13a09
Sha 256 on dist.torproject.org_torbrowser_6.0.5_sha256sums-unsigned-build
83af8ec2f8f56770a0a18bfe099cd4bf32e204bdcec8583575fb13a4f69b208a
No match, please put the easy to check and correct hashes back on that page as long as you dont explain in your long ago promised how to.
Making things not work and more difficult will only result in not checking at all anymore.

The hash does not match because the sha256sums-unsigned-build.txt file has the hashes from the builds without the code signing that is included in the final dmg files. We did not yet write instructions to remove the code signing to check that it matches the hashes from sha256sums-unsigned-build.txt, but it is still planned to do it:
https://trac.torproject.org/projects/tor/ticket/18925

However, sha256sums-unsigned-build.txt is maybe not what you want to use, depending on what you want to check. If you want to reproduce a build and check that it matches what is distributed, you will get a sha256sums-unsigned-build.txt file that you can compare with ours, and then the code signing needs to be removed from the dmg files we distribute (or added to the build you made) to check that it matches. We are working on ticket #18925 to make that easier. However if you just want to check that the dmg files you downloaded is really what we released, then you should not use the sha256sums-unsigned-build.txt file, but use the gpg signature (each dmg file is signed individually).

Georg, you are quoted in a rather terrifying story about a critical flaw affecting both TB and Tails version of TB:

http://www.theregister.co.uk/2016/09/18/mozilla_tor_flaws/
Mozilla will patch zero-day Firefox bug to fiddle man-in-the-middle diddle
Researcher revealed Tor flaw after initially being ignored
Darren Pauli
18 Sep 2016

> Mozilla will patch a flaw in its Firefox browser that could allow well-resourced attackers to launch man-in-the-middle impersonation attacks that also affects the Tor anonymity network. The flaw was first noticed by researchers describing the attacks against Tor ahead of the publication of a patch in version 6.0.5. "That vulnerability allows an attacker who is able to obtain a valid certificate for addons.mozilla.org to impersonate Mozilla's servers and to deliver a malicious extension update," Tor developer Georg Koppen says. "This could lead to arbitrary code execution. Moreover, other built-in certificate pinnings are affected as well. Obtaining such a certificate is not an easy task, but it's within reach of powerful adversaries such as nation states."

The attack was reported by a researcher who goes by Movrcx:

> The need to obtain a legitimate TLS certificate for addons.mozilla.org was the cause of the high cost of entry to the attack, something Movrcx says was "difficult to accomplish but not impossible. This attack enables arbitrary remote code execution against users accessing specific clearnet resources when used in combination with a targeting mechanism; such as by passively monitoring exit node traffic for traffic destined for specific clearnet resources," he wrote. "Additionally this attack enables an attacker to conduct exploitation at a massive scale against all Tor Browser users and to move towards implantation after selected criteria are met - such as an installed language pack, public IP address, DNS cache, stored cookie, stored web history, and so on."

(For those who have forgotten, some years ago a hacker (apparently living in Iran) was able to obtain the crown jewel of certificates, a genuine certificate claiming that he was wildcard at google.com. That deplorable incident was well handled by Mozilla.org, but that was some time ago and Mozilla's priorities may have changed.)

Disturbingly, Movrcx adds

> members of the Tor Project did not accept his initial private disclosure.

He gives more detail here:

https://hackernoon.com/tor-browser-exposed-anti-privacy-implantation-at…
Tor Browser Exposed: Anti-Privacy Implantation at Mass Scale
Credit: @Ox000000

> The combination of chaining the vulnerabilities described below allows a malicious exit node operator or global adversary to conduct a silent remote code execution attack on all platforms of the Tor Browser. This attack is not limited to just being hypothetical in nature and evidence shows that this attack has already been possible for a number of years. The list of vulnerable deployments to this attack includes the native Tor Browser for Windows, Linux, OSX and also includes Tor Browser installations on dedicated operating systems such as Tails and Whonix.

Concerning TP ignoring his warnings, he says:

> This vulnerability was originally described publicly in concept before the initial confirmation of the feasibility of the attack. Reaction to the theoretical disclosure was mocked as non-credible by Micah Lee and Andrea Shepard.

This seems indefensible, given that Movrcx had proven that the attack works and that Tor users were attempting to post warnings to this blog (which mysteriously never appeared) that an attack appeared to be in progress which possibly involved certificates.

[boklm:]

> There was a reboot of the server hosting the blog today, and for some reason the comments on recent blog posts disappeared.

S--t happens, I know that. But this deletion just seems much too convenient for USG interests. Maybe someone made a mistake accidentally on purpose. Or maybe current or former members of NSA/TAO intruded into the server (they certainly have the motive, means, and opportunity) and deleted the posts, making sure to time the deletion and to leave other misleading clues to encourage you to assume that the "accidental" deletion was due to an intermittent bug which happened to pop up during the reboot, a bug whose appearance is too rare to be worth trying to isolate and fix.

Well, NSA/TAO is not too rare. TP is a high priority target for them, there can be little doubt of that. And I say again, you have to worry not only about current members of NSA/TAO but a steadily growing number of "alumni" who are now working for effects-for-hire companies or even worse, for Comcast. (Seriously-- I could name names but then this post would be censored, eh?)

[gk:]

> We have not been censoring comments.

Well, my warnings about a mystery node with all zeros nickname--- was that Morcvx's testing the method?-- which never completes any circuits, whose appearance in Onion Circuits seems to be associated with the AdBlock Plus (not NoScript) updater running in Tails TB never appeared in the blog. My posts asking if others were seeing the same suspicious certificates I have been seeing never appeared. My posts asking whether it might be possible to persuade news sites likely to be attacked by sophisticated well-funded attackers, such as theintercept.com, to use onion services as a way to (as I understand it) avoid the problems with CAs, especially root CAs trusted by TB which are issued to extremely repressive governments or their FVEY-based contractors.

I believe that *you* believe TP is not censoring anyone here, but I fear that there is so much political pressure being put on Shari by FBI, USIC that someone else might see deleting or censoring posts which are too critical of the USG to be the lesser of two evils, compared to USG suddenly arresting every US TP employee and effectively finishing off the Project.

More and more I must conclude that the USA is not a safe home for TP and the whole kit and kaboodle, especially critical keyrings, should relocate to a safer place (maybe Iceland or Norway?).

I have already concluded we should not trust Roger's judgment (he apparently hired CIA agent David Chasteen to write code), and if there is any fire behind the veil of smoke covering up the firing of Jacob A, he too may have shown a lack of judgment in how our enemies would exploit his personal life to harm the Project.

And now I have to question Andrea's judgment. And even that of Micah Lee. Who's left? You and a few others who never write anything in the blog.

I've been trying hard to be supportive of the Shari regime but she's certainly not making it easy right now by remaining silent on so many critical issues, such as the question of whether or not TP supports a pardon for Edward Snowden, or what TP is doing to counter the dangerous demands for backdoors and free hacking powers--- not to mention the smearing of Snowden and the entire Tor community--- by FBI Director James Comey.

Georg, please, please, please, post a blog about the attack described by Movrcx and whether or not it can be mitigated. The new edition of Tails is due tomorrow but I don't know whether it will be delayed because of the emergency.

David Chasteen was not hired to write code, he was hired for his fine skillset as a project manager.

Personally i feel the torproject lost a lot by accepting his resignation. He was dedicated to the ideals of the project and his jobset would not have touched code.

I do recall it was ioerror who bullied Dave Chasteen into quitting his job.

And to mention people with US Millitary credentials movrcx is also former infantryman. Can't attack David Chasteen and then praise movrcx.

Sigghhh, so much work to undo the confusion ...

The attack was reported by a researcher who goes by Movrcx:

@movrcx (also @jmprcx, compare the avatar pictures) initiated #TorFork, while #TorStrike backfired. He planned to completely rewrite Tor and start his own network. He started by downloading the wrong repository from GitHub, much to the amusement of several TP staff, especially Isis Lovecruft. He asked Isis for help, and she gave him a pointer, but not without a teasing tweet about how Tor Project had finally tricked someone into picking up the torch and now all Tor Project personnel could go home: https://twitter.com/isislovecruft/status/766372347892920320 (Note @movrcx was @jmprcx there, and ... it's funny!).

Disturbingly, Movrcx adds

members of the Tor Project did not accept his initial private disclosure.

...

This seems indefensible, given that Movrcx had proven that the attack works and that Tor users were attempting to post warnings to this blog (which mysteriously never appeared) that an attack appeared to be in progress which possibly involved certificates.

With the above in mind, you'll have to reconsider whether he was going to be taken seriously by TP staff. Yet, there's more ...

In his article, https://hackernoon.com/tor-browser-exposed-anti-privacy-
implantation-at-mass-scale-bd68e9eb1e95, @movrcx states:

"The list of vulnerable deployments to this attack includes ... dedicated operating systems such as Tails ..."

As a TAILS user, I can tell you absolutely this is not true!. Unlike TBB, the fine Tails folks sensibly switched off add on auto-update (also TBB auto-update), because they take care of these updates in their six weekly update cycle (more frequently if there are emergency updates). In about:config, I find:

extensions.torbutton.no_updates = true
extensions.update.enabled = false

Thus, Tails was never exposed to @movrcx's attack.

Also, the document you should have read is this one:
"Deep down the certificate pinning rabbit hole of "Tor Browser Exposed"", by Ryan Duff (@flyryan).
http://seclists.org/dailydave/2016/q3/51.

As Ryan Duff explains, @movrcx claimed the exploit started to work when he recompiled Firefox after editing one of its configuration files (the one that contained all Certificate Authority (CA) certificates that Firefox would consider 'built-in' to refer presented certificates against: certdata.txt (See https://hg.mozilla.org/
mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt)). Specifically, he added the Burp CA to alow MITM proxy to work. That's another reason why @movrcx's claim was initially dismissed: it required a step that wasn't expectable, requiring on-site physical access (or an already pwned system).

Yet, here's the funny thing that got Ryan Duff and Erinn Atwater (@errorinn) intrigued that something really was wrong: although vanilla Firefox does not pin certificates by default, TBB switched this to do so, so the exploit should have failed even though @movrcx had compiled Burp CA in as a 'built-in' CA certificate.

Only when they got together (he writes "She had actually put a bunch of students on this task last night because she had the same concerns I did about this not being taken seriously.") did he work out why the exploit worked anyway and the truth of the matter emerge.

Essentially, Ryan explains: "It turns out that Mozilla actually doesn't use normal HPKP for certs related to their operations (like addons.mozilla.org). Instead, they use a form of static key pinning. ... it appears that with statically pinned certs, the only requirement for validation is that the certificate validates through a 'built in' CA. However, since it's not using libNSS to do the validation, [as it should have done]." And that is the actual bug that is to be fixed, not the one @movrcx thought he'd found (see https://twitter.com/errorinn/status/776859565908434944). (There's another one about Firefox's certificates expiring before they are due to be updated, but it's noticed now.)

(Someone posted a thank you to @flyryan and @movrcx, to which I posted not to forget to thank @errorinn as well, but that disappeared as the blog comments went AWOL.)

In any case, @movrcx was misattributing a Firefox bug to Tor, and @errorinn (amongst others) challenged him about why he notified Tor instead of Mozilla (https://twitter.com/errorinn/status/775823742270251010), which @movrcx never went on to do. Despite that, he tweets "And where tf is my bug bounty @Torproject?" (https://twitter.com/movrcx/status/776832762816892932).

Also, you asked:

Well, my warnings about a mystery node with all zeros nickname--- was that Morcvx's testing the method?-- which never completes any circuits, ...

I doubt it connects to @movrcx's exploit. In any case, your Tails 2.5 should not have been updating any add-ons. Tails 2.6 is now up for downloading. See if that changes anything - I expect not. (I also do not see an all zeroes nickname in my Onion Circuits. Screeshot please? imgur.com?)

It's a shame. He seems highly motivated and technically experienced, and this could have been a redeeming opportunity where he might have become an important contributer to Tor, but instead I think he's salted the Earth with TP.

Some of his tweets:

14 Sep - Angry, he talks of weaponising his exploit (https://twitter.com/movrcx/status/776193019406090240).

16 Sep - Incensed at his unfair treatment by the Tor Project, he threatens this: "Next time I'll be responsibly disclosing to the FBI, NSA, and GCHQ." (https://twitter.com/movrcx/status/776790169739530244).

16 Sep - Here @movrcx 'confirms' he has handed over another zero-day exploit he found in Tor to the Intelligence Community (https://twitter.com/movrcx/status/776864357598826496). (I think it's a bluff.)

19 Sep - Lately, he won't acknowledge @flyryan's or @errorinn's work (https://twitter.com/movrcx/status/778017637326524416).

20 Sep - Now, he won't be reasonable to @errorinn because 'she's a man...' (https://twitter.com/errorinn/status/778020004587458560).

So, you've got to ask yourself: are you going to spurn Tor based on what he says?

(Seriously-- I could name names but then this post would be censored, eh?)

Oh no, surely not! Why don't you try it and see? Test test test everything!

The announcements of Tails 2.6 and TB 6.0.5 should have stated clearly that they have been immunized (we hope) against the dangerous attack found by Movrcx.

Not sure what Tails did but that information is available on our blog post: "including the recently disclosed extension update vulnerability" with a link to the best write-up that was available back then.

The announcements of Tails 2.6 and TB 6.0.5 should have stated clearly that they have been immunized (we hope) against the dangerous attack found by Movrcx.

Even if Tails 2.6 is "immunized" against the dangerous attack found by Movrcx, Tails contains an unpatched security vulnerability in the Linux kernel that has the potential to unmask your anonymity.

According to Tails' official website, version 2.6 uses Linux kernel 4.6. As of the time of this post the said kernel is still unpatched by Debian (cf: https://security-tracker.debian.org/tracker/CVE-2016-5696).

Conclusion: Use Tails 2.6 at your own risk.

See:

   https://blog.patternsinthevoid.net/cve-2016-5696-and-its-effects-on-tor…

The "potential to unmask your anonymity" is seriously overegged. The attack, using TCP blind in-window DoS attack to try and bump Tor clients towards a hostile set of relays hardly helps a de-anonymisation attack because, as Isis Lovecruft explains, Tor builds new circuits whole from scratch.

I'm using Tails 2.6 right now (with Linux kernel 4.6) and I don't experience any DoS.

Thank you for the link. Tails is based on Debian, and Georg K is Tor Project's invaluable liason with Debian Project, so I'd like to hear his response.

The flaw you mention does sound scary:

> net/ipv4/tcp_input.c in the Linux kernel before 4.7 does not properly determine the rate of challenge ACK segments, which makes it easier for man-in-the-middle attackers to hijack TCP sessions via a blind in-window attack.

It is not clear to me that Tor sessions would be vulnerable; perhaps you can explain?

The Linux distributions which have reported that their version of earlier kernels are vulnerable appear to be:

> Metasploit, Red Hat, Ubuntu, Gentoo, SuSE, Mageia

but I don't see Debian on that list. I don't know what if anything that means, but possibly Debian stable is not vulnerable. Tails uses older kernels than current Debian stable, I believe, but may patch important bugs. GK would know much more about this, I think.

If you *are* correct, I imagine the Tails 2.7 announcement will include a reference to the flaw you cited.

There *are* no competitors: aye, there's the rub.

I completely agree with you that this accidental deletion is much too convenient for USG interests, and because TP is currently based in the USA, pressure can be brought. Maybe "they" got to someone.

Seems to be some kind of heavy moderation going on, certain questions aren't made through, such as, why boklm above replying on the seventeenth to a post written on eighteenth.
Hope you guys get your servers in order and check the date is correctly setted, thanks in advance for letting my comment through, I hope.

Long-time users of Tor and Tails will recall that, back before the Snowden leaks, Tails Project also had a blog. One day, it vanished.

Tails Project is based in France, which has government agencies which can act pretty much act as they please.

Tor Project is based in USA, which has government agencies which can pretty much act as they please.

There may still be a few nations whose governments are not so ugly as the FR or US governments. Maybe one of them would be a better home for TP?

What were they thinking when created this projects in FR or US? Or maybe it was decided by infiltrator, who promoted this locations, so now they have full control.

Anonymous

September 16, 2016

Permalink

Hello, how should I turn off auto-update for extensions and tor browser? So that I will not be affected by any future vulnerabilities of similar kind. I am a person used to doing update manually (apt-get update && apt-get dist-upgrade).

Thank you!

Possibilities include:

1. there are no backups

2. they don't know how (because a bug makes this too hard)

3. they don't have time (I have no doubt TP will insist this is the reason)

4. they could but are under threat of dire reprisal if they do

5. they could but know that our enemies will simply redelete them.

turn off auto-update for extensions
Tools (menu)
Add-ons Ctrl+Shift+A

click gear (symbol of a mechanical ring gear)
in menu, uncheck "Update Add-ons Automatically"

turn off auto-update for... tor browser (and search engines)
Tools (menu)
Options (windows) or Preferences (linnux)

Advanced (choice in left side)
Update (choice in top row)

"Tor browser updates: ..
Check for updates..let me choose.." (click the round circle)

"Automatically update:
Search engines" (uncheck box)

also for firefox help, there is "?" (a question mark symbol) at top right. Clicking "?" opens page in new tab https://support.mozilla.org/en-US/kb/advanced-panel-settings-in-firefox

Anonymous

September 18, 2016

Permalink

Thank you for updating tor browser.
After updating it crashed, please help.
Can you please update the roadmap for tor messenger ?

Anonymous

September 16, 2016

Permalink

thks

Can some TP employee state whether or not 6.0.5 fixes the critical flaw discussed here?

https://hackernoon.com/tor-browser-exposed-anti-privacy-implantation-at…
Tor Browser Exposed: Anti-Privacy Implantation at Mass Scale
Credit: @Ox000000

Can Movrcx clarify whether or not he/she ran the mysterious "node zero" (all zeros nickname, no information in Onion Circuits, never completes any circuits, appears as AdblockPlus updater is running in TB)? Or was that FVEY or RU or some such entity?

For what it may be worth, TB 6.0.5 appears to run on my Debian system.

Thanks! Any idea about the mysterious node which never completes any circuits, has a nickame consiting of a long string of zeros (according to Tor Circuits in Tails 2.5), and appears to be associated with the AdBlock Plus updater running (in Tails 2.5)?

I know, Tails is a separate project, but since they closed their own blog they are impossible to reach.

TIA.

And thanks for working to improve security in Debian and Tor!

Can you provide up to date instructions for reaching Tails using TM from a Calyx account?

I have never been able to figure this out.

Years ago I tried regularly to reach Tails devs in the old chat room, but they were almost never available,.

Oops, panic is not optimal for putting two and two together, but now I see that the post about Tails 2.6 says TB has been upgraded to TB 6.0.5 in Tails 2.6, so current versions of TBB and Tails are immune against the attack found by Movrcx. Whew!

so current versions of TBB and Tails are immune against the attack found by Movrcx. Whew!

Don't be too happy just yet.

Tails contains an unpatched security vulnerability in the Linux kernel that has the potential to unmask your anonymity.

According to Tails' official website, version 2.6 uses Linux kernel 4.6. As of the time of this post the said kernel is still unpatched by Debian (cf: https://security-tracker.debian.org/tracker/CVE-2016-5696).

Conclusion: Use Tails 2.6 at your own risk.

Anonymous

September 18, 2016

Permalink

Yo
where did all the comments go?
and why was the check.torproject.org link down for over 20 hours?