Javascript exploit actively used against TorBrowser
lists.torproject.org
Javascript exploit actively used against TorBrowser
1–10 of 138 posts
Re: Javascript exploit actively used against TorBrowser
#2Confirmed in the next message in the thread: 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.
Re: Javascript exploit actively used against TorBrowser
#3Are there immediate actions for inoculation, e.g. disabling SVG, and/or detection, i.e. if this has been triggered?
Re: Javascript exploit actively used against TorBrowser
#4Are there immediate actions for inoculation, e.g. disabling SVG, and/or detection, i.e. if this has been triggered?
noscript would probably work, seeing that it relies on javascript to function
Re: Javascript exploit actively used against TorBrowser
#5I reversed the shellcode, it's almost exactly the same used in 2013 (freedom hosting): https://twitter.com/TheWack0lian/status/803736507521474560
Re: Javascript exploit actively used against TorBrowser
#6I reversed the shellcode, it's almost exactly the same used in 2013 (freedom hosting): https://twitter.com/TheWack0lian/status/803736507521474560
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.
(Maybe the EFF wants to do this)
Re: Javascript exploit actively used against TorBrowser
#7If 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.
Re: Javascript exploit actively used against TorBrowser
#8I reversed the shellcode, it's almost exactly the same used in 2013 (freedom hosting): https://twitter.com/TheWack0lian/status/803736507521474560
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.
Re: Javascript exploit actively used against TorBrowser
#9If 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.…
Unfortunately based on my experience training activists/journalists all over the world, the average user at risk in the field struggles to use TAILS.
Re: Javascript exploit actively used against TorBrowser
#10I 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)