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

11–20 of 138 posts

Re: Javascript exploit actively used against TorBrowser

#11

Post by micaksica »

secfirstmd wrote: post #9
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.…

Unfortunately based on my experience training activists/journalists all over the world, the average user at risk in the field struggles to use TAILS.

What's their biggest struggle with it?

PS, if you're ever on the US West Coast or in Singapore, drop me a DM. I'll buy you a drink someplace.

Re: Javascript exploit actively used against TorBrowser

#12

Post by secfirstmd »

micaksica wrote: post #11
secfirstmd wrote: post #9

Earlier quoted context omitted.

Unfortunately based on my experience training activists/journalists all over the world, the average user at risk in the field struggles to use TAILS.

What's their biggest struggle with it? PS, if you're ever on the US West Coast or in Singapore, drop me a DM. I'll buy you a drink someplace.

Honestly? Many things:

-It's tricky for a non-technical user to setup

-It disrupts their regular workflow

-People get frustrated with speeds of Tor etc

-People get frustrated with Captcha (Dam Cloudflare!) and other things caused by using Tor in a safe manner.

-People get annoyed as it doesn't solve their problems and exposure on mobile

-You have to restart to run it

-They can't run their regular programs on it - MS Office, Outlook, Adobe, etc.

-It's Linux based, so a big mental jump for most people coming from Windows (or most people not at the command line on OS X)

-It's hard to access files on other drives

-Documentation and TAILS is only available in certain languages

-It often has driver problems - e.g Macbook Pro 2015 WIFI issues

-In developing states, computer literacy is low, so anything other than the norm (Windows) is confusing

-In developing states, hardware tends to be slow (often counterfeit) so running TAILS in RAM is slow

-People lose the USB sticks they put TAILS on (also many counterfeits, so they often fail or have a false size)

-TAILS often requires training, which not everyone has access to

-Skills fade for digital security training with journalists/activists is often quite high, especially if they don't need it that often.

-the list goes on............

Don't get me wrong, I think it's great (as is Qubes, Subgraph etc) but we need to be realistic about it's limitations for the majority of people. Especially if we want to be sensible and try to tailor advice, training and tools to their realistic threat models.

P.S Definitely, I'm on the West Coast probably once a year. Ditto you if your ever in Dublin (Ireland, not that fake one in California :) or London!

Re: Javascript exploit actively used against TorBrowser

#13

Post by lima »

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:

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

Re: Javascript exploit actively used against TorBrowser

#14

Post by splesjaz »

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

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.

Re: Javascript exploit actively used against TorBrowser

#15

Post by ikeboy »

tlrobinson wrote: post #10

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…

One word: whonix.

Re: Javascript exploit actively used against TorBrowser

#16

Post by secant »

tlrobinson wrote: post #10

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…

A slight aside, but is Docker on Unix running natively then?

Re: Javascript exploit actively used against TorBrowser

#17

Post by micaksica »

splesjaz wrote: post #14
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.…

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…

Working within an assumed breach scenario, the VM is defense in depth. Firefox has holes, and it will continue to be relatively easily exploitable as long as TBB allows for plugins and JavaScript by default. There is reticence from TBB team to disable JS by default even in the face of a few of these 0days, so you have to protect TBB users a level down from the browser and assume it'll be popped.

There are Windows "sandboxes" like Bromium, and as stated, IIRC EMET will stop the stack pivot here.

Re: Javascript exploit actively used against TorBrowser

#18

Post by easychewie »

tlrobinson wrote: post #10

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…

> fullscreen Tor browser

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

Re: Javascript exploit actively used against TorBrowser

#19

Post by tlrobinson »

secant wrote: post #16
tlrobinson wrote: post #10

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…

A slight aside, but is Docker on Unix running natively then?

Typically yes, unless you set it up in a VM yourself (or using docker-machine)

Re: Javascript exploit actively used against TorBrowser

#20

Post by giancarlostoro »

ikeboy wrote: post #15
tlrobinson wrote: post #10

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…

One word: whonix.

ParrotSec OS is another OS that tries to fully block all connections not going through Tor, out of the box.
Post reply on HN