Tor Browser 6.0.7 is released

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!

Anonymous

November 30, 2016

Permalink

Folks, after update, remember to go to about:config and set the following to false:

app.update.auto
app.update.enabled
extensions.update.autoUpdateDefault
gfx.downloadable_fonts.woff2.enabled
gfx.downloadable_fonts.enabled
gfx.font_rendering.opentype_svg.enabled
svg.in-content.enabled
svg.marker-improvements.enabled

Those are not good recommendations. You should keep the updater enabled and if you want to have a more secure Tor Browser slide the security slider to a higher position. Otherwise you'll make you an easier fingerprinting target.

How does not downloading fonts make it less secure, we were hit by font exploits not long ago.

Addons has unique installation timestamps stored within firefox, I'd rather download addon updates manually, not have firefox phoning home all the time and tell them when and what addons i've installed.

Your advice is misleading at best.

Customizing individual settings makes your browser fingerprint more unique.
Disabling downloadable fonts will increase security if there's a vulnerability in the font parser, but when every client except yours downloads fonts, it can be told that the person visiting various pages is the same person; https://panopticlick.eff.org/
That's why the Tor project should disable SVG and downloadable fonts on "high" security slider setting, rather than recommending people to configure it manually.
Therr should, of course, be a choice to do it manually, but TBB should warn the user when a setting being changed can increase fingerprintability.

This is simply a tradeof between security and anonymity. The only way to have both is if the security slider does this, or an option is added to keep downloading them but just not parse them

They can't detect what fonts you downloaded unless you enable javascript

fonts are usually on another server anyway (fonts.google.com)

NEVER DOWNLOAD ANY FONTS

agreed.
in the last weeks updates for 'downthemall'
and 'flashgot' were offered by mozilla update
but there were no new versions on both homepages.

Anonymous

December 01, 2016

Permalink

Major flaw in update: it deletes all bookmarks since last update and entire downloads directory. Just lost about 30 hours of work.

The update is not touching your bookmarks nor your downloads directory. Thus, whatever happend on your machine it seems rather unlikely that Tor Browser is responsible for it. What operating system were you using?

EDIT: On second thought: What could have happened is that you lost the bookmarks you make after your update got applied but before you restarted. This should not happen on Windows and OS X but if you are on a Linux system this may happen. There are at least two ways to solve this right away:

1) Setting `app.update.staging.enabled` to `false` in your about:config should prevent it avoiding the update application in the background.

2) As soon as the update in the background gets applied you'll see an indicator in the upper right corner of your taskbar indicating that your Tor Browser is ready for restart right now. Restarting at that moment prevents bookmark etc. loss as well.

Anonymous

December 01, 2016

Permalink

Dear developers;

Please add a "Restore Default Size" button in torbutton, I'm using Whonix' TBB in Qubes OS and it always for some reason gives me the wrong resolution

Thank you so much for all the hard work!!

Anonymous

December 01, 2016

Permalink

I recently had to have my OS reinstalled and all my bookmarks have gone from TB. There were a lot of them. Is there ant way to recover them?
Thanks

Your old operating system, and its file systems, are gone?

It sounds like the answer is no.

You might want to make a backup copy of your bookmark file in the future if you want to keep it across reinstalls.

Anonymous

December 01, 2016

Permalink

I did the update via the autoupdate feature. All works finde.

Now i checked the addons. Clicked on check for updates. And it updates the https everywhere and say to restart.

So which version should we use at the moment for https everywhere? And is it a bad idea to click on update addons? Is it strange that my tor browser doesn't use the newest version of https everywhere?

It looks like I have version 5.27. Newest is 5.28? https://www.eff.org/files/Changelog.txt

Thanks for help !

Anonymous

December 01, 2016

Permalink

I have just updated to 6.0.7
When I use https://ipcim.com/hu/ to check the pathways, the result is that a server in France is always at the top of the country list no matter how many times I change the circuit or even change identity. This is a bit strange any ideas?

The last version of I used - 6.6 I think - had different relays every time the new tor circuit was changed. So why is it that these 'entry guards' are on some versions of TOR but not on others? I would have thought that having a fixed IP like that would make tracking easier, but I am not an expert like TOR developers are.

If the first entry guard you get is bad, then changing it is good.
But there are strong math proofs showing that without entry guards, almost everyone will be deanonymized at least once.
So the point of entry guards is to have most people never deanonymized, instead of everyone being deanonymized for short periods of time. The argument is that in totalitarian dictstorships, losing your privacy even once will get you targeted, so entry guards were made so if you get a bad one your privacy is invaded over and over which is no worse than once, and if you get a good entry guard you're safe forever (except intrusions into your computer by deliberate 0days(backdoors) that the NSA threatens to kill people for not putting in their software; project BULLRUN requires all US software companies to make remotely exploitable buffer overruns in all their software, aka "magic golden key", aka sabotage/treason).

Solution:
edit/create a file named 'torrc' (no extension)
\Browser\TorBrowser\Data\Tor\

Add:

#Fix Entry country
EntryNodes {NL}

#Fix Exit country
ExitNodes {CH}

#Block NSA partner countries and unknown countries
ExcludeNodes {GB},{FR},{US},{AU},{NZ},{??}

#Ensure no exceptions for node settings even when nodes are not found
StrictNodes 1

#Improve SSD life span
AvoidDiskWrites 1

#Stop using port 80/9001
FascistFirewall 1
FirewallPorts 443
ReachableDirAddresses *:443
ReachableORAddresses *:443

#Other settings
HiddenServiceStatistics 0

It's also dangerous to create circuit with {US},{DE},{GB} nodes
these countries work together and use supercomputers to record and decrypt traffic

This can't be done because the torrc file says:

# This file was generated by Tor; if you edit it, comments will not be preserved
# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it

Anonymous

December 01, 2016

Permalink

G-Data writes "The purpose is to retrieve the network interfaces’ mac address and report it to a server."

My question is: if the user set a custom MAC address for the network interface, does this vulnerability uses the spoofed address used by Windows, or does it get the real MAC address directly from the network hardware?

Most likely it uses a standard Windows API for obtaining the MAC address, which would probably return the effective (spoofed) address. To get the real burned-in MAC would probably be a bunch of different APIs for various hardware types/vendors, although I'm not a Windows programmer so for all I know there might be a standard API for obtaining this information. The payload is meant to be as reliable (and therefore, simple) as possible, so including code paths for interacting with many different drivers is likely out of the question, at least at this point in time.

Most coverage has been about the attack and exploit vector, but you can probably find an analysis of the payload itself somewhere (I seem to remember The Intercept covered it, I think). You can probably even get a neutered copy of the payload from one of the research groups' sites (I briefly saw one come up recently, but I can't remember the name) and try it yourself. All I know is it was very similar to the one used to attack Playpen in the past.

Keep in mind that, as I understand, it also collects your hostname, serial number, and other pieces of information, and makes a direct connection to its home server, thus revealing your un-torrified IP address. And it could have done just about anything the author wanted it to, once it made its way into your system and was executed. So MAC spoofing is rather insignificant in the grand scheme of things.

Sorry I couldn't be more help, but I hope I pointed you in the right direction.

Anonymous

December 01, 2016

Permalink

Updating straight from 6.0.5 to 6.0.7 on Linux consumed a huge amount of disk space, then ran out of space and failed. Now TBB won't even start.

To be more precise, it was running on an 800MB partition which contained nothing but TBB.

A full uncompressed TBB takes up what? 200MB? 250MB? Can't understand why it would need more than 800MB to do an update:

Surely:
250MB old TBB
100MB mar file
250MB new TBB = 600MB total

Would be great if updates could be done in a way that doesn't cause so much bloat.

Also, +1 to the person on the 6.0.6 update thread who asked that the updater check if enough space is available *before* it starts applying the update.

Thanks.

The incremental updates are usually just a couple of MiB as they contain just the diff from the previous version. But using 800MiB with a clean Tor Browser and updating it, even using a full update, should be more than enough.

I think checking for available disk space before updating and warning the user if there is a risk of it being not sufficient is a good idea. We have https://trac.torproject.org/projects/tor/ticket/18186 for that. See the comments which could explain why those 800MiB were maybe not enough and how to workaround that.

No they won't. God will kill these facist pigs and burn them all im hell forever for destroying a once great nation. They will dienhorrible deaths for making the USA as bad as China. Today is the beginning of Satan's 3 and a half year dominion over mankind. The terrorists were way off in thinking of American citizens as "the great satan"; it's the government that is, and not just US government, but most governments. I read the book though and know the ending.

Anonymous

December 01, 2016

Permalink

Let me see:

* Deanonymisation bug in Firefox - let's patch it!
* Another deanonymisation bug in Firefox - let's patch it, too!
{repeat ad nauseam}

Why Firefox, being continously weak element of Tor Bundle is forced upon us? Why not to return to solution like Vidalia?

By the way, does Torproject endorse Whonix? It is not susceptible to any Tor Browser vulnerability and provides better isolation than Tails.

Because Vidalia is not a browser. That said browsers will probably always be a weak element in the bundle as they have a vastly larger attack surface than any of the other components. We could consider Chrome instead but that would not give us a Tor Browser in the short nor the medium term due to scarce engineering capacities at least.