
An example of exploiting two fixed vulnerabilities in Firefox on Windows - DyslexicAtheist
https://github.com/0vercl0k/CVE-2019-11708
======
geofft
Note this is not a 0-day, this is a fully-worked-out example of exploiting two
vulnerabilities fixed in May and June of this year. Worth reading for
knowledge, but as an end user, just make sure you've restarted your browser at
least once since June and haven't turned off auto-update.

~~~
leeoniya
[https://archive.is/20130414124019/http://ha.ckers.org/blog/2...](https://archive.is/20130414124019/http://ha.ckers.org/blog/20070803/mozilla-
says-ten-fucking-days/)

~~~
Natfan
That link 404s, here's one that works:
[https://web.archive.org/web/20150102232217/ha.ckers.org/blog...](https://web.archive.org/web/20150102232217/ha.ckers.org/blog/20070803/mozilla-
says-ten-fucking-days/)

------
DangerousPie
Can we add something to the title to clarify that these bugs were fixed months
ago? Eg. "(fixed in June)"?

It's still an interesting post, but nowhere near as worrying for Firefox users
as it sounds.

~~~
dang
Ok, added above.

------
crumbshot
Interested readers should check out the author's earlier work exploiting
CVE-2019-9810:
[https://github.com/0vercl0k/CVE-2019-9810](https://github.com/0vercl0k/CVE-2019-9810)

And their fantastically detailed writeup of a PoC they wrote for that
vulnerability: [https://doar-e.github.io/blog/2019/06/17/a-journey-into-
ionm...](https://doar-e.github.io/blog/2019/06/17/a-journey-into-ionmonkey-
root-causing-cve-2019-9810/)

This exploit is different in that they use the arbitrary read/write primitive
gained by CVE-2019-9810 to flip a couple of bits and patch out a few
instructions with the effect of removing the security boundary between a
normal web page and XPCOM. The interesting difference in this exploitation
approach is there's no need for ROP chains and shellcode, as you have all the
XPCOM components available to use.

Once they're in that privileged context in the content process, they escape
its sandbox by exploiting CVE-2019-11708. This works by sending an particular
IPC message to the parent process, that causes a web page of the exploiter's
choice to load in that process. In this case, the choice is to exploit
CVE-2019-9810 again, then use XPCOM components to drop an executable to disk
and run it.

Awesome work, and a real pleasure to read, it's satisfying to see such well-
commented and clear exploit code.

------
rahuldottech
The thing is, most of these exploits also affect Tor browser, because it's
built upon Firefox.

Other than using a VM or a live distro like Tails , is there any other way for
OR users to be _safer_ when running the regular Tor browser bundle, such as by
utilising third-party sandbox software?

~~~
ErikCorry
Most likely you are _less safe_ using Tor than using a regular Firefox or
Chrome with no VPN, because using Tor automatically means nation state
attackers are going to target you. So you have to do extra work just to break
even. Google EgotisticalGiraffe for details.

~~~
rahuldottech
There's no way this is true. Even if nation state actors _are_ more likely to
target you just for using Tor, even if it's for completely regular browsing,
Tor provides a _lot_ of additional protection and anonymity.

~~~
DyslexicAtheist
I initially got hung up on the GP assertion that users are _most likely_
better off with Firefox. It depends on the threat model. But after thinking
about it for a while, I agree with GP.

Those people thinking about such topics constantly might not be the average
user. I would not feel safe installing Tor on my parents computer and telling
them it is safer to do all their browsing now with Tor.

Threat models matter otherwise we'll end up applying wrong security tools:
*"use Signal. use tor." when the right thing would have been to meet in person
wearing a fake mustache, and keep a pebble in your shoe to change your walk.

GP's advise makes sense for anyone who does not know what Tor is (most
people). They are off better if we symlink their "Internet Button" from the
desktop to Firefox, install uBlock and NanoDefender for them. If they're still
adventurous teach them about creating/editing "multitab containers" (though I
bet we've lost most of them by now).

~~~
dmos62
> GP's advise makes sense for anyone who does not know what Tor is

Whether or not someone knows of Tor doesn't influence her threat model or
privacy requirements, and therefore doesn't influence what measures can help.
Other than that, I agree that you have to be aware of the threat model and
what given tools provide.

------
est31
> It uses CVE-2019-9810 for getting code execution in both the content process
> as well as the parent process and CVE-2019-11708 to trick the parent process
> into browsing to an arbitrary URL.

I wonder why is the privileged parent process even allowed to execute unsigned
Javascript from the network? IIRC it already has eval support turned off. I
get that it's hard to get rid of privileged Javascript completely (Servo
thankfully made the choice early on to not do that at all), but is there any
feature that requires downloading & executing Javascript from the network in
the privileged parent process?

~~~
kevingadd
Signed javascript isn't really a concept that exists anywhere. I'd love it if
it did, it's a gaping hole in the internet security model. Mainline FF loads
lots of unsigned user-controlled JS as-is (prefs.js, for example) so the
closest thing you get is signing on entire extension bundles.

There is the Subresource Integrity mechanism
([https://developer.mozilla.org/en-
US/docs/Web/Security/Subres...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity)) as a stopgap for this but it
doesn't really provide something useful in this case because the load target
has to be known in advance and you can't provide a hash for top-level content
in the URL.

~~~
est31
Add ons must be signed by Mozilla I think. Also, add ons that have privileged
access require a special signature that Mozilla only uses for their own add
ons. That's what I meant with signed Javascript. Anyway, this wasn't my main
point. It's why you load and execute Javascript from the network in the first
place in the content process. It feels to me that banning JS loading would
have helped here a great deal and would make exploitation of similar bugs much
harder.

------
toyg
What’s so special about this old vulnerability targeting the few people who
turn on bigInt support (it’s disabled by default, I believe)...?

------
mr_woozy
Is it fixed as of what version?

~~~
est31
CVE-2019-11708 is fixed in Firefox 67.0.4 and CVE-2019-9810 is fixed in
Firefox 66.0.1.

[https://www.mozilla.org/en-
US/security/advisories/mfsa2019-1...](https://www.mozilla.org/en-
US/security/advisories/mfsa2019-19/)

[https://www.mozilla.org/en-
US/security/advisories/mfsa2019-0...](https://www.mozilla.org/en-
US/security/advisories/mfsa2019-09/)

~~~
mr_woozy
danka danka

------
hu3
I get permission denied when trying to view the bug:

[https://bugzilla.mozilla.org/show_bug.cgi?id=1559858](https://bugzilla.mozilla.org/show_bug.cgi?id=1559858)

~~~
saagarjha
Access to security bugs is usually restricted.

~~~
qxnqd
Even to bugs that have already been fixed?

~~~
jfk13
There's generally (and sensibly) some delay between fixing the bug and opening
up the report.

~~~
tedunangst
It's been six months.

