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 (note: as of Nov. 4, 2017, this link is non-public while Mozilla works on a fix for Firefox). 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.

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.

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.

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.

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%!

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.

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.

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.

My problem has nothing to do with clicking on links, the workaround for that works perfectly fine.
What I'm talking about is the fact that when I open my local webpage using file:///path-to-local-webpage/index.html in the url bar I see errors in the console like
ReferenceError: $ is not defined
and
NetworkError: A network error occurred
The local webpage used to work like a charm without any warnings/errors in the console so this update is clearly breaking more than just links.

I suggest to remove the "file://" support and (!) in-browser pdf functionality from Torbrowser.

About a more than half a year ago, someone asked on this blog how safe the "file://" functionality was, answer; safe.
While it is not.
Your browser should not have this functionality because it is for browsing online and not for browsing on your computer.

Regarding pdf, we all know that pdf's are widely used for (malware) attacks, also in combination with webbugs. So it is a bad idea to use your browser for opening pdfs.
Especially when you realize that probably the most of Torbrowser users don't have the functionality enabled to use Torbrowser as their standard browser (and there you go, well actually the pdf-webbug).

Pdf reader leaking tricks? If you use the well known pdf reader from that company than also is the largest tracking company in the world (2o7.net, .. anyone?) you should at least take some time to just look at the preferences of your program (actually you should do that with all the programs you use (!).
Disable any extra functionality that has to do with connecting to the internet and disable embedded script functions.

But probably better is to make sure that your firewall is configured well, do not white list the pdf readers (among many others, work with monitored whitelisting, etc.)
The best off course I can think of is to just own a Tails distribution, and use that when needed.

Unfortunately the mozilla bug is protected so we do not know how it works, which computer process was leaking the ip address?
Could it have been avoided when the process was not on the whitelist of your (extra) firewall config?

Using Torbrowser is a very nice standard protection in defence towards tracking companies, but if you really care about not giving away your ip address then it is probably essential to work with a firewall to prevent (all time populair) webbugs triggering other computer/program processes to connect with the internet directly. (Usual suspects, your Office program, your Pdf reader, your media player, your real standard browser (!)).
And off course to protect yourself from malware attacks, because most malware is not coming right away along as malware but usually need at least another step to fetch the real malware from the internet.
That process does probably not (always) succeed with a firewall blocking that new connection.

Torbrowser, very nice.
Extra firewall? Absolutely necessary to protect your safety and privacy (more).
Use at least Torbrowser + firewall program.
Use them both I should say.
And I hope that we get to know which extra computer process was activated to connect with the internet with this bug, so we can protect ourself and not being completely dependent on Torproject.

TBB is my default Linux browser, and I had to stand on my head to make it so. I keep a lot of hypertext documentation on my local hard drive and view it with the default browser.

Among other things I display weather statistics from my own weather station. The *weewx* package creates *.html documents on my local hard drive on a schedule. I've had to switch to *iceweasel* to see them. These weather pages potentially contain links to other Web-based resources. I guess I'll just have to remember I'm not using a hardened browser while visiting those.

Oh and what about your sweeping generalsomething? Last time I checked TB isn't a magic panacea. You like to use TB to look at PDF instead of sand-boxing that shit? How's that sane? You trust code written for public internet use (which has been re-purposed admirably for flexibility with tor network) to look at pdf (PDF!?) securely? If you cannot allocate some more memory to that crappy vm you run or sandbox a separate document reader process then you shouldn't criticize someone for giving a damn about TB's security.

Hasn't TB retained the ability to load local server addresses (with modification)? I haven't checked because I like to separate control. If so then why keep file:/// support at all, just a moving landmine.

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.

Filippo and We Are Segment Team are also supporter of Italian Hackers Embassy events, fostering non commercial aggregation of Italian Hackers Communities! Kudos and thanks for all you are doing in such a nice way! -naif

It could be any number of things. Perhaps it involved interacting with some character device, which would explain why it affects Linux and OSX, but not Windows. Like the file URI parsing code is probably identical between Linux, OSX, and Windows versions of Firefox. The majority of the code is operating system agnostic, so the fact that it only affects *nix systems strongly narrows down the possibilities.

While I don't know for sure and can only speculate, my best guess is that it is related to the browser accessing a character device or something similar, since that's the only big difference between the behavior of their filesystem layouts. It wouldn't be a bug in the URL parsing code because the vast majority of code between Firefox for different operating systems is the same. I would be surprised if there were any significant difference between the Linux/OSX and Windows versions when it comes to file parsing.

first think about how local addresses can be exploited to leak in tor browser, they are blocked by default for a reason, and require your action to enable. second think about where files are located when invoking file:// urls and where the code which handles it is located.

from the wording it clearly impacts the local.file:// usage not when files are viewed on the server

so how to exploit? convince you to open a file://url to a local file (convince you to download it before), the file is formed to include remote assets possibly including identifiers to track back. when loaded via file:// local file runs local address and by default may not always obey proxy as local addresses tend to not traverse gateway.

not deliberate or malicious in design, but kind of like trying to compel adobe flash to obey proxy with jedi mind tricks

i do not know & understand what is a 'specially crafted URL' : thx for the update (especially to the italian-team of course).
- still the same bugs (several last versions are affected) : your update interferes with no-script (before the update be done:downloaded:installed) on the old version - i suspect a manipulation related at blog tor (it is NOT a safe browsing & compromises my surf & login).
- still the same insecure settings : ssl/tls - i understand that an user -lambda- needs surfing everywhere & quickly without hassle but it does not suit me (it is NOT a safe browsing & compromises my surf & login).
conclusion : it becomes too much ambiguous : security vs anonymity / security OR anonymity

You really don't have to worry about that when it comes to Tails. Let's go through each of the fingerprinting methods in turn, from the bleepingcomputer article in that blog post:

1) Screen Resolution - Tails will automatically start Tor Browser with a standard resolution. It even warns you if you try to resize the browser in a way that would give away your screen resolution.

2) Number of CPU Virtual Cores - If I remember correctly, Tor Browser blocks the hardwareConcurrency function. Even if it doesn't, this is a rather limited signature on its own.

3) AudioContext - Tor Browser has recently fixed this issue.

4) List of Fonts - This only allows distinguishing the broad class of operating system. For Tails, it merely tells someone that you are using Linux. Tails doesn't attempt to hide the fact that it is Tails, either, as their version of Tor Browser is unique to Tails (but still indistinguishable among different Tails users).

Nobody said we'll never use that feature to do X. Moreover, *just* configuring Tor Browser to use AF_UNIX sockets would not have helped in this case. That proxy setting would have got bypassed, as well. So, there is more we would need and how to do that best for *all* OS X and Linux users still needs to get figured out it seems. I think that's important, don't get me wrong. But it's not done by just entering different proxy details into the browser settings.

Something not right. Tried to update, got warnings. Downloaded from website and it failed all time i downloaded the signature. Only Tor i could download not signature. I then copied the signature and got BAD SIGNATURE. Here it is:

Recent Updates

There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.0.1-alpha from the usual place on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release likely by the end of the month.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor 0.4.0.1-alpha is the first release in the new 0.4.0.x series. It introduces improved features for power and bandwidth conservation, more accurate reporting of bootstrap progress for user interfaces, and an experimental backend for an exciting new adaptive padding feature. There is also the usual assortment of bugfixes and minor features, all described below.

Changes in version 0.4.0.1-alpha - 2019-01-18

Major features (battery management, client, dormant mode):

When Tor is running as a client, and it is unused for a long time, it can now enter a "dormant" state. When Tor is dormant, it avoids network and CPU activity until it is reawoken either by a user request or by a controller command. For more information, see the configuration options starting with "Dormant". Implements tickets 2149 and 28335.

The client's memory of whether it is "dormant", and how long it has spent idle, persists across invocations. Implements ticket 28624.

There is a DormantOnFirstStartup option that integrators can use if they expect that in many cases, Tor will be installed but not used.

Major features (bootstrap reporting):

When reporting bootstrap progress, report the first connection uniformly, regardless of whether it's a connection for building application circuits. This allows finer-grained reporting of early progress than previously possible, with the improvements of ticket 27169. Closes tickets 27167 and 27103. Addresses ticket 27308.

When reporting bootstrap progress, treat connecting to a proxy or pluggable transport as separate from having successfully used that proxy or pluggable transport to connect to a relay. Closes tickets 27100 and 28884.

Tor 0.3.5.7 is the first stable release in its series; it includes compilation and portability fixes, and a fix for a severe problem affecting directory caches. Tor 0.3.4.10 and 0.3.3.11 are also released today; please see the official announcements for those releases if you are tracking older stable versions.

The Tor 0.3.5 series includes several new features and performance improvements, including client authorization for v3 onion services, cleanups to bootstrap reporting, support for improved bandwidth- measurement tools, experimental support for NSS in place of OpenSSL, and much more. It also begins a full reorganization of Tor's code layout, for improved modularity and maintainability in the future. Finally, there is the usual set of performance improvements and bugfixes that we try to do in every release series.

There are a couple of changes in the 0.3.5 that may affect compatibility. First, the default version for newly created onion services is now v3. Use the HiddenServiceVersion option if you want to override this. Second, some log messages related to bootstrapping have changed; if you use stem, you may need to update to the latest version so it will recognize them.

We have designated 0.3.5 as a "long-term support" (LTS) series: we will continue to patch major bugs in typical configurations of 0.3.5 until at least 1 Feb 2022. (We do not plan to provide long-term support for embedding, Rust support, NSS support, running a directory authority, or unsupported platforms. For these, you will need to stick with the latest stable release.)

Below are the changes since 0.3.5.6-rc. For a complete list of changes since 0.3.4.9, see the ReleaseNotes file.

Changes in version 0.3.5.7 - 2019-01-07

Major bugfixes (relay, directory):

Always reactivate linked connections in the main loop so long as any linked connection has been active. Previously, connections serving directory information wouldn't get reactivated after the first chunk of data was sent (usually 32KB), which would prevent clients from bootstrapping. Fixes bug 28912; bugfix on 0.3.4.1-alpha. Patch by "cypherpunks3".