Tor Browser 6.5a5-hardened is released
A new hardened Tor Browser release is available. It can be found in the 6.5a5-hardened distribution directory and on the download page for hardened builds.
This release features an important security update to Firefox and contains, in addition to that, an update to NoScript (2.9.5.2) and a fix of our updater code so it can handle unix domain sockets.
The Firefox 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.
Note regarding updating: We still require the same update procedure as experienced during an update to 6.5a4-hardened: a dialog will be shown asking to either set `app.update.staging.enabled` or `extensions.torlauncher.control_port_use_ipc` and `extensions.torlauncher.socks_port_use_ipc` to `false` (and restart the browser in the latter case) before attempting to update. The fix for this problem is shipped with this release and we will be back to a normal update experience with the update to 6.5a6-hardened. We are sorry for this inconvenience.
Here is the full changelog since 6.5a5-hardened:
- All Platforms
- Update Firefox to 45.5.1esr
- Update NoScript to 2.9.5.2
- Bug 20691: Updater breaks if unix domain sockets are used
Comments
Please note that the comment area below has been archived.
For those who don't know how
For those who don't know how different Tor Browser-hardened from the stable release: https://lists.torproject.org/pipermail/tbb-dev/2016-June/000382.html
Was the previous hardened
Was the previous hardened version vulnerable to the recent exploit? I understand it was a memory corruption vuln of some kind caused by the use of some clever JavaScript. I'm assuming it was probably a heap-based attack (will have to dig into the details), so SSP wouldn't apply if that's the case, but what about AddressSanitizer or other measures. Has anyone tested the previous hardened against a proof-of-concept exploit? It's interesting to see how much more secure hardened really is in real-world scenarios.
I also would like to know
I also would like to know this. I remember seeing some of the Tor Browser folks saying "somebody should test it", but I don't know if anybody did that. It could be you! Let us know what you learn.
I don't subscribe to the
I don't subscribe to the mailing list, but I did run across a link to a post that had the exploit code in it [1]. I could tell the developer of it is obviously a lot smarter than I am, but I might just be able to glue the pieces together well enough to create a test harness of sorts.
I've since learned from an article [2] that it was a use-after-free vuln, so heap-based, and I believe HeapSanitizer does attempt to catch use-after-free conditions.
I can't make any promises, but I think I might play around with this and see if I come up with anything.
1. https://lists.torproject.org/pipermail/tor-talk/2016-November/042639.ht…
2. http://arstechnica.com/security/2016/11/firefox-0day-used-against-tor-u…