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…