Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Javascript exploit actively used against TorBrowser

lists.torproject.org

Post reply on HN
Print view View original

31–40 of 138 posts

Re: Javascript exploit actively used against TorBrowser

#31

Post by ryuuchin »

micaksica wrote: post #7

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.…

> 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.

Re: Javascript exploit actively used against TorBrowser

#32

Post by ryuuchin »

lima wrote: post #13

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…

> 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).

Re: Javascript exploit actively used against TorBrowser

#33

Post by gruez »

tlrobinson wrote: post #22
easychewie wrote: post #18

Earlier quoted context omitted.

> fullscreen Tor browser Tor recommends not going full-screen, since window size can be used as one of several identifiers.

I mean fullscreen within the VM's desktop (no need for normal GNOME/KDE/whatever desktop), which itself may not be fullscreen on host OS. It would act like a native app. If you quit the browser it shuts down the VM.

>I mean fullscreen within the VM's desktop

so like... maximized?

Re: Javascript exploit actively used against TorBrowser

#34

Post by zwindl »

tlrobinson wrote: post #22
easychewie wrote: post #18

Earlier quoted context omitted.

> fullscreen Tor browser Tor recommends not going full-screen, since window size can be used as one of several identifiers.

I mean fullscreen within the VM's desktop (no need for normal GNOME/KDE/whatever desktop), which itself may not be fullscreen on host OS. It would act like a native app. If you quit the browser it shuts down the VM.

Ah, You mean the VM only have one program which is Tor browser, and when Tor terminated the VM should terminated with it.

Re: Javascript exploit actively used against TorBrowser

#35

Post by micaksica »

ryuuchin wrote: post #31
micaksica wrote: post #7

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.…

> 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 s…

> 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.

Sure, but we can't get TBB rewritten overnight to work instantly with Chromium, and I'm sure there'd be a lot of push back on that.

Re: Javascript exploit actively used against TorBrowser

#36

Post by splesjaz »

micaksica wrote: post #35
ryuuchin wrote: post #31

Earlier quoted context omitted.

> 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 s…

> 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. Sure, but we can't get TBB rewritten overnight to work instantly with Chromium, and I'm sure there'd be a lot of push back on that.

Well yea but this isn't something that we discovered today it's been years sadly :(

Re: Javascript exploit actively used against TorBrowser

#37

Post by random234528 »

micaksica wrote: post #8
slipstream- wrote: post #5

I 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.

It's on a CP site (giftbox). The exploit got loaded on the confirmation page after logging in.

Re: Javascript exploit actively used against TorBrowser

#38

Post by mmaunder »

micaksica wrote: post #8
slipstream- wrote: post #5

I 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.

Background for the uninitiated: https://www.eff.org/deeplinks/2016/09/playpen-story-fbis-unp...

Re: Javascript exploit actively used against TorBrowser

#40

Post by cyphar »

ryuuchin wrote: post #29

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.
Post reply on HN