13 ms·
Javascript exploit actively used against TorBrowser
- giancarlostoro 10y agoHas 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?
- schoen 10y agoConfirmed in the next message in the thread: https://lists.torproject.org/pipermail/tor-talk/2016-November/042640.html https://lists.torproject.org/pipermail/tor-talk/2016-Novembe... (the vulnerability appears to exist in upstream Firefox as well). Seems to relate to SVG animation.
- JumpCrisscross 10y agoAre there immediate actions for inoculation, e.g. disabling SVG, and/or detection, i.e. if this has been triggered?
- slipstream- 10y agoI reversed the shellcode, it's almost exactly the same used in 2013 (freedom hosting): https://twitter.com/TheWack0lian/status/803736507521474560 https://twitter.com/TheWack0lian/status/803736507521474560
- revelation 10y agoThis 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. (Maybe the EFF wants to do this)
- micaksica 10y agoThis 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.
- curveship 10y agoIt's not much, but the code redirects the user to a 'member.php' page after 2 seconds. So whatever the target was, it probably had a member.php page.
- random234528 10y agoIt's on a CP site (giftbox). The exploit got loaded on the confirmation page after logging in.
- micaksica 10y agoEh, with that being the case, I don't personally have too much sympathy. +1 to FBI on this being pretty well targeted; you had to have had a successful login for them to be attempting this in the first place. It's about as precise as they can get; you're only going after users that are active members of the service. They are at least being reasonable in who they are targeting. I can't really think of how they can be more targeted in attempting to deanonymize people in the network. I don't like this whole NIT garbage because I'm afraid this will lead to fishing expeditions, where you just root everyone on an .onion that happens to visit it, and then clean up with a multitude of search warrants later and hope you get something. I also don't believe it's the FBI's (or America's) job to play world police. -1 to the FBI, at least: they were (once again) actively serving CP on a compromised server again, which seems like something you shouldn't be doing as an LEA fighting the distribution of the content. Illegal actions shouldn't be taken to fight crime. Distributing the thing you are fighting is the definition of the abyss having gazed into you.
- micaksica 10y agoIf 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.
- vilhelm_s 10y agoI'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.
- micaksica 10y agoFine. Replace Tails with Whonix-Workstation and Whonix-Gateway, if you need to worry about leaking the IP address.
- vilhelm_s 10y ago"If"? Are there any Tor users who don't need to worry about leaking their IP address? Then why do they use Tor in the first place? The Tor project itself seems to promote Tails much more than Whonix, which seems very odd to me.
- tlrobinson 10y agoI 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)
- ikeboy 10y agoOne word: whonix.
- giancarlostoro 10y agoParrotSec OS is another OS that tries to fully block all connections not going through Tor, out of the box.
- nilved 10y agoAnother: Qubes
- secant 10y agoA slight aside, but is Docker on Unix running natively then?
- tlrobinson 10y agoTypically yes, unless you set it up in a VM yourself (or using docker-machine)
- easychewie 10y ago> fullscreen Tor browser Tor recommends not going full-screen, since window size can be used as one of several identifiers.
- lima 10y agoAs 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: - 2013/08: XPCOM RCE (https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/firefox_svg_plugin.rb https://github.com/rapid7/metasploit-framework/blob/master/m...) - 2013/08: __exposedProps__ (https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/firefox_proto_crmfrequest.rb https://github.com/rapid7/metasploit-framework/blob/master/m...) - 2014/03: WebIDL RCE (https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/firefox_webidl_injection.rb https://github.com/rapid7/metasploit-framework/blob/master/m...) - 2015/03: PDF.js RCE (https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/firefox_pdfjs_privilege_escalation.rb 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-found-in-the-wild/ 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/product_id-3264/Mozilla-Firefox.html 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.
- ryuuchin 10y agoThis 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.
- cyphar 10y agoBecause 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.
- SparkyMcUnicorn 10y agoLike this? https://github.com/Eloston/ungoogled-chromium https://github.com/Eloston/ungoogled-chromium
- cyphar 10y agoThere is currently only one maintainer of that code, and there is this disclaimer in the readme: > DISCLAIMER: Although it is the top priority to eliminate bugs and privacy-invading code, there will be those that slip by due to the fast-paced growth and evolution of the Chromium project.
- AgentME 10y agoDoes this affect the regular (non-TBB) current version of Firefox?
- gcp 10y agoThe bug yes. The exploitability, unclear. Current release Firefox has some minimal content sandboxing protections enabled but TBB is based on older ESR.
- mirimir 10y agoThis only works in Windows, right?
- schoen 10y agoThis exploit is Windows-specific, though the vulnerability appears not to be.
- mirimir 10y agoThanks. If you could say more about that, please do. Abstracting from 'The exact functionality is unknown but it's getting access to "VirtualAlloc" in "kernel32.dll" and goes from there.' to Linux etc is over my head.
- schoen 10y agoThe underlying vulnerability has to do with a memory corruption of some sort in Firefox's SVG rendering, which is a code base that is shared across platforms. So probably an analogous memory corruption exists on other platforms, because it's compiled from the same C++. While it's possible that it's not exploitable outside of Windows, there is no specific reason to assume it won't be. But the exploit here with the ROP chain, calling Windows APIs, etc., is apparently Win32-specific and doesn't have binary code that could run successfully on other platforms. The setup for the exploit is apparently primarily in the Javascript function craftDOM() which makes some SVG objects and modifies some of their properties, presumably in a way that triggers an underlying bug in Firefox's SVG support. There is also a Win32 object code payload in the string object thecode, which would not be able to run unmodified on another platform. Also, the ROP chain code is likely to be Windows-specific in several respects. Indeed, the statement throw"Bad NT Signature"; seems to be actively giving up the attack if it detects a non-Win32 environment.
- mirimir 10y agoThanks, that helps.
- 10y ago
- deleted 10y ago[deleted]
- brian-armstrong 10y agoThis will make a very interesting postmortem. I'm curious how they escaped from js
- dispose13432 10y agoSo going on a not-HSTS site through tor can now infect your computer (through the MITM of the exit node)? Seems that using regular internet is actually safer now.
- schoen 10y agoThe same vulnerability apparently also exists in Firefox, which Tor Browser is based on.
- dispose13432 10y agoBut its worse on Tor. Regular internet has a few protections: 1. Google safe browsing 2. AdBlocking 3. Websites try to keep their reputation. Tor exit nodes, on the other hand, have no reputation (and if one gets sullied, spin up another) and costs money.
- NinjaTrappeur 10y agoI have one question: the list of exit nodes is public, we can know at any time the circuit's complete list of servers. Does something prevents us from rating tor exit nodes according to their "transparency" and add this rating in the consensus file? Does anybody already worked on that? I cannot find anything on the internet…
- schoen 10y agoThere are projects that scan exit nodes for various heuristics; if they find very bad behavior, they report it to the Tor Project to request a BadExit flag. However, there's no kind of continuum of rankings, just BadExit or not. My impression from talking to people working on this a few years ago was that they wanted to be a little bit secretive about exactly what they scan for, in order to make it harder for malicious exit operators to anticipate the scans or to distinguish the scans from end-user traffic. There was a suggestion this is an activity that anybody can engage in: if you can think of an attack against Tor users that you know how to detect, you can write your own client that tests for that thing (modifying the path selection algorithm to ensure that you test every exit node!) and then start running your tests. People will be interested in your results.
- ns8sl 10y agoI've quit using TOR. It seems to have been targeted by law enforcement and now this.
- schoen 10y agoThis was an upstream Firefox bug, so you should probably quit using Firefox if you're concerned about bugs like this. (Using Tor does change who can attempt to attack you with such bugs -- and maybe who is motivated to.)
- ivank 10y agohttps://github.com/mozilla/gecko-dev/commit/cba49f2392f772a089b18fff8221368c5abf22bf https://github.com/mozilla/gecko-dev/commit/cba49f2392f772a0...
- mirimir 10y agoFrom Roger Dingledine on tor-talk https://blog.torproject.org/blog/tor-browser-607-released https://blog.torproject.org/blog/tor-browser-607-released https://dist.torproject.org/torbrowser/6.0.7/ https://dist.torproject.org/torbrowser/6.0.7/