
Javascript exploit actively used against TorBrowser - secfirstmd
https://lists.torproject.org/pipermail/tor-talk/2016-November/042639.html
======
micaksica
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.

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

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

~~~
TD-Linux
An easier solution would be to enable e10s. It should be on by default in the
next ESR, and I know TBB has been working to make their patches compatible
with it.

~~~
gcp
Not just e10s, they also need to enable the sandboxing, i.e. it requires
Firefox 50 at least.

It should actually be easier for Tor to enable stricter sandboxing than in the
default Firefox, though, as presumably they have to care less about
compatibility.

------
slipstream-
I 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)

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

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

~~~
micaksica
Eh, 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.

~~~
desci
> Illegal actions shouldn't be taken to fight crime.

I disagree with that and I am on favor of illegal actions against criminal
actions.

I just think that this is not FBI's role. Illegal organizations should assume
the illegal work. If FBI commits crimes to fight crimes, then to me they're as
criminal as the folks they're hunting, and therefore I would treat them the
same way I treat the "regular" criminal people.

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

~~~
easychewie
> fullscreen Tor browser

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

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

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

------
schoen
Confirmed in the next message in the thread:
[https://lists.torproject.org/pipermail/tor-
talk/2016-Novembe...](https://lists.torproject.org/pipermail/tor-
talk/2016-November/042640.html) (the vulnerability appears to exist in
upstream Firefox as well). Seems to relate to SVG animation.

------
giancarlostoro
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?

------
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...](https://github.com/rapid7/metasploit-
framework/blob/master/modules/exploits/multi/browser/firefox_svg_plugin.rb))

\- 2013/08: __exposedProps__ ([https://github.com/rapid7/metasploit-
framework/blob/master/m...](https://github.com/rapid7/metasploit-
framework/blob/master/modules/exploits/multi/browser/firefox_proto_crmfrequest.rb))

\- 2014/03: WebIDL RCE ([https://github.com/rapid7/metasploit-
framework/blob/master/m...](https://github.com/rapid7/metasploit-
framework/blob/master/modules/exploits/multi/browser/firefox_webidl_injection.rb))

\- 2015/03: PDF.js RCE ([https://github.com/rapid7/metasploit-
framework/blob/master/m...](https://github.com/rapid7/metasploit-
framework/blob/master/modules/exploits/multi/browser/firefox_pdfjs_privilege_escalation.rb))

\- 2015/08: The file stealing exploit:
[https://blog.mozilla.org/security/2015/08/06/firefox-
exploit...](https://blog.mozilla.org/security/2015/08/06/firefox-exploit-
found-in-the-wild/)

\- [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/...](https://www.cvedetails.com/vulnerability-
list/vendor_id-452/product_id-3264/Mozilla-Firefox.html)

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

~~~
tdullien
Also, it is safe to say that ChakraCore (the JS interpreter inside Edge) is
much more broken / easier to find bugs in than Firefox, at least at the
moment.

~~~
Strom
Why is that safe to say?

~~~
tdullien
I looked at both.

------
JumpCrisscross
Are there immediate actions for inoculation, _e.g._ disabling SVG, and/or
detection, _i.e._ if this has been triggered?

~~~
gruez
noscript would probably work, seeing that it relies on javascript to function

------
mirimir
This only works in Windows, right?

~~~
schoen
This exploit is Windows-specific, though the vulnerability appears not to be.

~~~
mirimir
Thanks. 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
The 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
Thanks, that helps.

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

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

~~~
SparkyMcUnicorn
Like this?

[https://github.com/Eloston/ungoogled-
chromium](https://github.com/Eloston/ungoogled-chromium)

~~~
cyphar
There 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
Does this affect the regular (non-TBB) current version of Firefox?

~~~
gcp
The bug yes. The exploitability, unclear. Current release Firefox has some
minimal content sandboxing protections enabled but TBB is based on older ESR.

------
ivank
[https://github.com/mozilla/gecko-
dev/commit/cba49f2392f772a0...](https://github.com/mozilla/gecko-
dev/commit/cba49f2392f772a089b18fff8221368c5abf22bf)

------
mirimir
From 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/)

------
brian-armstrong
This will make a very interesting postmortem. I'm curious how they escaped
from js

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

~~~
Buge
Exit nodes will also steal any unencrypted passwords and put malware in any
binaries you download. It's been happening for years.

In China the "regular internet" intercepts http and inserts javascript malware
to create a DDOS botnet.

~~~
dispose13432
Yes, but I'm not talking about downloading exes or logging onto gmail (and
definitely not putting credentials on a site using HTTP) or anything.

I'm talking about going anywhere on Tor can infect you.

~~~
torrio888
[https://blog.torproject.org/blog/how-report-bad-
relays](https://blog.torproject.org/blog/how-report-bad-relays)

------
ns8sl
I've quit using TOR. It seems to have been targeted by law enforcement and now
this.

~~~
schoen
This 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.)

