pasted from here: https://blog.torproject.org/tor-browser-709-released

  Tor Browser 7.0.9 is released
by gk | November 03, 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. 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

Tags
tor browser
tbb
tbb-7.0

     Join the discussion...

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?

     Reply

boklm said:

November 03, 2017

In reply to Tails users and users of our… by Anonymous (not verified)
Permalink

Yes, Whonix users are not affected.

     Reply

Anonymous (not verified) said:

November 03, 2017
Permalink

Important update ...

     Reply

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.

     Reply

pastly said:

November 03, 2017

In reply to Why until Monday for the… by Anonymous (not verified)
Permalink

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.

     Reply

boklm said:

November 03, 2017

In reply to Alpha users are ideally… by pastly
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.

     Reply

Anonymous (not verified) said:

November 03, 2017

In reply to The main reason is that the… by boklm
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%!

     Reply

Anonymous (not verified) said:

November 04, 2017

In reply to I bet that on modern CPUs… by Anonymous (not verified)
Permalink

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.

     Reply

boklm said:

November 04, 2017

In reply to I bet that on modern CPUs… by Anonymous (not verified)
Permalink

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.

     Reply

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.

     Reply

Anonymous (not verified) said:

November 03, 2017

In reply to I support removing file://… by Anonymous (not verified)
Permalink

Other tools WILL leak your IP and other data.

     Reply

Anonymous (not verified) said:

November 03, 2017

In reply to I support removing file://… by Anonymous (not verified)
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.

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.

     Reply

Anonymous (not verified) said:

November 04, 2017

In reply to I support removing file://… by Anonymous (not verified)
Permalink

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.

     Reply

Anonymous (not verified) said:

November 03, 2017

In reply to I support removing file://… by Anonymous (not verified)
Permalink

How can I test my local jekyll blog builds then? How can I watch videos without fearing leaks?

     Reply

Anonymous (not verified) said:

November 03, 2017

In reply to How can I test my local… by Anonymous (not verified)
Permalink

Using a program that's completely isolated and prevented from making ANY network access.

     Reply

Anonymous (not verified) said:

November 04, 2017

In reply to Using a program that's… by Anonymous (not verified)
Permalink

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.

     Reply

Anonymous (not verified) said:

November 03, 2017

In reply to I support removing file://… by Anonymous (not verified)
Permalink

Is there a rule in the about:config where this functionality that can be disabled?

     Reply

Anonymous (not verified) said:

November 04, 2017

In reply to Is there a rule in the about… by Anonymous (not verified)
Permalink

No. There should be one.

     Reply

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…

Click here to read the complete article