If TBB leads want to run Firefox with JavaScript "default on", then Tor Browser Bundle needs to be messaged as insecure. Either that or turn on NoScript and inform people what bad shit can happen when their browser is interpreting arbitrary code in a not-so-sandboxed manner. TBB is not a solution against targeted deanonymization attacks.
This is neither the first nor is the last 0day in Firefox that will affect TBB.
IMO the best practical mitigation against these attacks is sandboxing with an amnesic system like Tails, as even as a VM it will leak a lot less information about the machine it is running on and requires burning both a Firefox 0day and a VM escape to get any real information outside of the real IP address of the user and some basic things out of /proc (although Tails may protect against the latter now). Also, as the whole VM goes away when it's closed, you're not getting persistence on that machine if you just pop the browser.
A 30 second glance at the source code makes it looks like this exploit pivots to attacker-controlled memory on the heap, and spawns a thread using kernel32.dll. As EMET has hardening against attacks like this, I am curious if this exploit works at all on EMET-enabled Windows systems.
> A 30 second glance at the source code makes it looks like this exploit pivots to attacker-controlled memory on the heap, and spawns a thread using kernel32.dll. As EMET has hardening against attacks like this, I am curious if this exploit works at all on EMET-enabled Windows systems.
EMET can be bypassed so it's no guarantee that it would stop the exploit (but it would probably stop THIS exploit). I don't know if some modification would be able to bypass EMET or other mitigations.
A better solution would be to run javascript in a sandbox (as is done in Chrome/Chromium based browser) which has a much higher barrier to exit.
I've never understood the Tails threat model, and this comment does not really help. You say that it will prevent the attackers from learning any information, except the real IP address of the user. But hiding the IP address of the user is the whole point of Tor.
If you give that up, then what's even the point? The state can simply drive a black van to your house and get the rest of your information at their leisure.
VMs are all nice and that but if the exploit can compromise the TBB it's too late already, sandboxing needs to happen in the browser on Linux you can use namespaces + strict seccomp rules but don't know what one would use for Windows.
First priority would be to sandbox the browser and work your way down if you want to sandbox more stuff.
For Windows EMET can help to prevent certain exploits I guess but yea a browser that can access anything on the filesystem & system calls is badstuff.
This likely points to this being an FBI "network investigative technique".* I'm really curious where this attack was injected, as that also means that that .onion is also compromised.
My guess? Some darknet market.
* Sure, this could be some type of awkward false flag, but it seems unlikely to my gut.
This might be a good moment to point out that you should not put the IP+path into your browsers navigation field unless you are looking for a surprise home search.
I feel like Tor Browser should just spin up a fresh VM with a minimal Linux distribution and fullscreen Tor browser, with the VM's only networking tunneled through Tor.
I think Hyper-V can do graphics as well and it looks like bhyve added some sort of graphics support earlier this year, but xhyve has none. Not sure if there are any other lightweight hypervisors that support graphics (or maybe just use a protocol like X11 or VNC?).
Docker for Mac and Docker for Windows have done a great job of hiding the fact that it's using virtualization from users (but doesn't need graphics, of course)
Has nobody tried putting Gopher and Tor together? Would probably yield slightly better results given how minimalist Gopher is, mostly text based. It might not work as well if you try to have a "community" on Tor, but it would be interesting to know how Gopher works out in Tor if at all?
As much as I love Mozilla and their philosophy, it has to be said that - if you have any sort of worries about security - using Firefox is a bad choice and borderline reckless.
It lacks even basic exploit mitigations that other browser have had for years now (most importantly a feature-complete sandbox).
Right now, Firefox is just a single process with zero separation of privileges. Any bug in the rendering code is a potential RCE. Writing exploits for Firefox vulnerabilities is well within a strong amateur's reach and this headline does not surprise me at all.
This is a (probably incomplete) list of all public exploits in the past three years:
Publicly known as in, with a fully functional Metasploit exploit, and most of them through JavaScript, so 100% reliable. ASLR isn't going to help with interpreter bugs. This is 90s level bad!
And those are just the publicly known ones. With a code base as large as Firefox, it'd be foolish to assume to assume that there aren't any private 0days. Just take a look at this list:
Project Electrolysis is a step in the right direction, but it will take a LONG time to mature. Last time I checked, it was just for process separation and did not provide any security guarantees. Chromium had a fair bit of sandbox escapes during the first years, and there's no reason to believe this is going to be different with Firefox. If have high hopes for their Rust re-implementation, but that's not going to be usable any sooner.
In the meantime, there's nothing like Chrome/Chromium security-wise. Not even close.
When was the last time there was a reliable, public Chrome exploit with a sandbox escape? The only one I can think of was the Hacking Team exploit, which used a Windows kernel 0day to escape the sandbox.
Chrome's security team is probably the strongest in the industry and they poured an absurd amount of effort into Chrome's security. And it being open source means that I can use without worrying about backdoors or data leakage.
Just to provide some balance: Chrome exploits are not as rare as you claim in this post. Pretty much any time Pwn2Own or similar contests are held, with non-trivial prize money, somebody brings a fully working Chrome exploit.
If you check https://zerodium.com/program.html you can see that the current market prize for a Chrome exploit with sandbox escape is about 80k USD. Firefox is cheaper (30k USD), but only by a bit more than factor 2.
(I've been working on security vulnerabilities pretty continuously since 1998, so I somewhat know what I am talking about)
In general, for any major browser: Given the size, complexity, and code churn, an attacker just needs enough motivation / time.
> When was the last time there was a reliable, public Chrome exploit with a sandbox escape? The only one I can think of was the Hacking Team exploit, which used a Windows kernel 0day to escape the sandbox.
Don't forget that it's not just the sandboxing and Chrome/Chromium based browsers can mitigate entire classes of bugs thanks to win32k lockdown. A recent example was a Flash bug which required access to some of the blacklisted system calls (GDI I think).
Chromium had a fair bit of sandbox escapes during the first years, and there's no reason to believe this is going to be different with Firefox.
I agree. Note that people still find sandbox escapes against Chrome anyway. Yes, sometimes they use the OS, but due to how the sandboxing works that's to be expected.
Even Microsoft Edge is better at this.
CVE counting, especially the ones published by the developers themselves, aren't a very good measure of security.
I learned this the hard way. Got a drive-by virus infection on Firefox a couple of years ago. I clicked on a link from a google search, and that website completely infected my machine, .exes started running. I thought it was a browser popup at first. It was not. Scary stuff. With Chrome, I feel much safer, and no such thing has happened again. To you, the reader, this might just be an anecdote. But to me it was very frustrating and time-consuming. These days, I always secure my browser properly, allowing only minimal amounts of cross-site requests, JavaScript and plugins.
The shellcode is Windows specific, but the bug is in Firefox. It is possible there is something server side sending the proper code depending on the user agent.
This may be an unpopular opinion here but if the TorBrowser folks cared about security they should switch to a Chromium based browser. The sandbox provided by it would be robust and well tested as it's used in Chrome.
I don't see why the two objectives of having a secure browser and the privacy/anonymity provided by Tor have to be diametrically opposed. You can have both.
Because removing all of the Google-related features from Chromium would be a very large task indeed. Quite a few people have discussed it within Tor (and IIRC some people started working on it) but it might not be as good of an idea as you might initially think.
The bug yes. The exploitability, unclear. Current release Firefox has some minimal content sandboxing protections enabled but TBB is based on older ESR.
[+] [-] micaksica|9 years ago|reply
This is neither the first nor is the last 0day in Firefox that will affect TBB.
IMO the best practical mitigation against these attacks is sandboxing with an amnesic system like Tails, as even as a VM it will leak a lot less information about the machine it is running on and requires burning both a Firefox 0day and a VM escape to get any real information outside of the real IP address of the user and some basic things out of /proc (although Tails may protect against the latter now). Also, as the whole VM goes away when it's closed, you're not getting persistence on that machine if you just pop the browser.
A 30 second glance at the source code makes it looks like this exploit pivots to attacker-controlled memory on the heap, and spawns a thread using kernel32.dll. As EMET has hardening against attacks like this, I am curious if this exploit works at all on EMET-enabled Windows systems.
[+] [-] secfirstmd|9 years ago|reply
[+] [-] ryuuchin|9 years ago|reply
EMET can be bypassed so it's no guarantee that it would stop the exploit (but it would probably stop THIS exploit). I don't know if some modification would be able to bypass EMET or other mitigations.
A better solution would be to run javascript in a sandbox (as is done in Chrome/Chromium based browser) which has a much higher barrier to exit.
[+] [-] vilhelm_s|9 years ago|reply
If you give that up, then what's even the point? The state can simply drive a black van to your house and get the rest of your information at their leisure.
[+] [-] splesjaz|9 years ago|reply
[+] [-] slipstream-|9 years ago|reply
[+] [-] micaksica|9 years ago|reply
My guess? Some darknet market.
* Sure, this could be some type of awkward false flag, but it seems unlikely to my gut.
[+] [-] revelation|9 years ago|reply
(Maybe the EFF wants to do this)
[+] [-] djsumdog|9 years ago|reply
[+] [-] tlrobinson|9 years ago|reply
I think Hyper-V can do graphics as well and it looks like bhyve added some sort of graphics support earlier this year, but xhyve has none. Not sure if there are any other lightweight hypervisors that support graphics (or maybe just use a protocol like X11 or VNC?).
Docker for Mac and Docker for Windows have done a great job of hiding the fact that it's using virtualization from users (but doesn't need graphics, of course)
[+] [-] easychewie|9 years ago|reply
Tor recommends not going full-screen, since window size can be used as one of several identifiers.
[+] [-] pjmlp|9 years ago|reply
It is a type 1 hypervisor and DX is supported since a few versions.
Also the foundation of Windows 10 containers and secure kernel.
[+] [-] mtgx|9 years ago|reply
https://www.whonix.org/
[+] [-] ikeboy|9 years ago|reply
[+] [-] secant|9 years ago|reply
[+] [-] schoen|9 years ago|reply
[+] [-] giancarlostoro|9 years ago|reply
[+] [-] lima|9 years ago|reply
It lacks even basic exploit mitigations that other browser have had for years now (most importantly a feature-complete sandbox).
Right now, Firefox is just a single process with zero separation of privileges. Any bug in the rendering code is a potential RCE. Writing exploits for Firefox vulnerabilities is well within a strong amateur's reach and this headline does not surprise me at all.
This is a (probably incomplete) list of all public exploits in the past three years:
- 2013/08: XPCOM RCE (https://github.com/rapid7/metasploit-framework/blob/master/m...)
- 2013/08: __exposedProps__ (https://github.com/rapid7/metasploit-framework/blob/master/m...)
- 2014/03: WebIDL RCE (https://github.com/rapid7/metasploit-framework/blob/master/m...)
- 2015/03: PDF.js RCE (https://github.com/rapid7/metasploit-framework/blob/master/m...)
- 2015/08: The file stealing exploit: https://blog.mozilla.org/security/2015/08/06/firefox-exploit...
- [The FBI exploit (2016-ish)]
- This one.
Publicly known as in, with a fully functional Metasploit exploit, and most of them through JavaScript, so 100% reliable. ASLR isn't going to help with interpreter bugs. This is 90s level bad!
And those are just the publicly known ones. With a code base as large as Firefox, it'd be foolish to assume to assume that there aren't any private 0days. Just take a look at this list:
https://www.cvedetails.com/vulnerability-list/vendor_id-452/...
Even Microsoft Edge is better at this.
Project Electrolysis is a step in the right direction, but it will take a LONG time to mature. Last time I checked, it was just for process separation and did not provide any security guarantees. Chromium had a fair bit of sandbox escapes during the first years, and there's no reason to believe this is going to be different with Firefox. If have high hopes for their Rust re-implementation, but that's not going to be usable any sooner.
In the meantime, there's nothing like Chrome/Chromium security-wise. Not even close.
When was the last time there was a reliable, public Chrome exploit with a sandbox escape? The only one I can think of was the Hacking Team exploit, which used a Windows kernel 0day to escape the sandbox.
Chrome's security team is probably the strongest in the industry and they poured an absurd amount of effort into Chrome's security. And it being open source means that I can use without worrying about backdoors or data leakage.
[+] [-] tdullien|9 years ago|reply
If you check https://zerodium.com/program.html you can see that the current market prize for a Chrome exploit with sandbox escape is about 80k USD. Firefox is cheaper (30k USD), but only by a bit more than factor 2.
(I've been working on security vulnerabilities pretty continuously since 1998, so I somewhat know what I am talking about)
In general, for any major browser: Given the size, complexity, and code churn, an attacker just needs enough motivation / time.
[+] [-] ryuuchin|9 years ago|reply
Don't forget that it's not just the sandboxing and Chrome/Chromium based browsers can mitigate entire classes of bugs thanks to win32k lockdown. A recent example was a Flash bug which required access to some of the blacklisted system calls (GDI I think).
[+] [-] gcp|9 years ago|reply
It's a separate project from e10s (though it depends on it): https://wiki.mozilla.org/Security/Sandbox
Chromium had a fair bit of sandbox escapes during the first years, and there's no reason to believe this is going to be different with Firefox.
I agree. Note that people still find sandbox escapes against Chrome anyway. Yes, sometimes they use the OS, but due to how the sandboxing works that's to be expected.
Even Microsoft Edge is better at this.
CVE counting, especially the ones published by the developers themselves, aren't a very good measure of security.
[+] [-] Kenji|9 years ago|reply
[+] [-] FoxInBoxers|9 years ago|reply
This realization may be enough for me to finally switch, if so.
[+] [-] witty_username|9 years ago|reply
Could you elaborate? I'm curious what they do for security.
[+] [-] JumpCrisscross|9 years ago|reply
[+] [-] gruez|9 years ago|reply
[+] [-] adrianN|9 years ago|reply
[+] [-] mirimir|9 years ago|reply
[+] [-] dsl|9 years ago|reply
[+] [-] schoen|9 years ago|reply
[+] [-] ryuuchin|9 years ago|reply
I don't see why the two objectives of having a secure browser and the privacy/anonymity provided by Tor have to be diametrically opposed. You can have both.
[+] [-] cyphar|9 years ago|reply
[+] [-] AgentME|9 years ago|reply
[+] [-] gcp|9 years ago|reply
[+] [-] ivank|9 years ago|reply
[+] [-] mirimir|9 years ago|reply
https://blog.torproject.org/blog/tor-browser-607-released
https://dist.torproject.org/torbrowser/6.0.7/
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] brian-armstrong|9 years ago|reply
[+] [-] dispose13432|9 years ago|reply
Seems that using regular internet is actually safer now.
[+] [-] Buge|9 years ago|reply
In China the "regular internet" intercepts http and inserts javascript malware to create a DDOS botnet.
[+] [-] schoen|9 years ago|reply
[+] [-] ns8sl|9 years ago|reply
[+] [-] schoen|9 years ago|reply
(Using Tor does change who can attempt to attack you with such bugs -- and maybe who is motivated to.)