1559845 - Firefox breakout observed in the wild

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, task)

Description

[Hayden Parker]

Attachment: 0day.js

Today we received a targeted phishing attack against some employees that appears to exploit the latest version of firefox on OSX (67?) and escapes the sandbox to gain execution on the machine.

Our endpoint detection tooling shows that the malicious page caused firefox to shell out a curl command that downloaded and ran the actual malware payload.

I've attached the payload that we believe contains the exploit code. I can attach the full HTTP session from our investigation as well.

Comment 1

[Hayden Parker]

Attachment: Adding the full session from burp

Comment 2

[Daniel Veditz [:dveditz]]

At first glance this looks like a JIT issue, though there's some references to DocShell. We ultimately need to find two bugs (at least) in here: the initial exploit and then how they escaped the sandbox to download their curl payload

Comment 3

[Frederik Braun [:freddy]]

Attachment: exploit main.js

This version of the exploit doesn't contain remote URLs. It basically reloads itself with the first line modified containing (const TYPE = 'worker' or 'final'). You need to create these two copies to fully reproduce.

Comment 4

[Jan de Mooij [:jandem]]

Attachment: Shell testcase

Repros for me in the JS shell on rev 51deb82b686d, before the fix for bug 1544386 landed, not on the next rev with the fix. Testcase also has similar array.pop() calls.

Comment 5

[Frederik Braun [:freddy]]

The Sandbox escape happens by reloading itself as a modal window (which the Prompt:Open message provides). This gives you a process switch to the parent. From there, the attacker can just launch the exploit again.
E.g.,
docShell.messageManager.sendAsyncMessage("Prompt:Open", {uri: "XXX own source code again here"});.

Comment 6

[Frederik Braun [:freddy]]

Discussing the Sandbox escape is in bug 1559858 now.

Comment 7

[Jan de Mooij [:jandem]]

Requested mozilla-release approval for bug 1544386.

Comment 8

[Christian Holler (:decoder)]

Attachment: Reduced shell test

Comment 9

[Jan de Mooij [:jandem]]

Note: the tests in this bug do not repro on ESR60 (but ESR is definitely vulnerable). The test in bug 1544386 comment 0 repros and the patch fixes it.

Comment 10

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/b46f3ba0c766
user: Jan de Mooij
date: Sat May 12 11:46:51 2018 +0200
summary: Bug 1460381 - Support sealed and non-extensible dense elements on native objects. r=anba

For reference, both decoder's and Jan's attached shell testcases bisect to this particular changeset, since it uses .seal, however, the underlying cause may be something else.

Comment 11

[Jan de Mooij [:jandem]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #10)

autobisectjs shows this is probably related to the following changeset:

It's only related in that we used to deoptimize all dense elements when sealing an object - so we'd never hit the buggy code before that change. That's just an 'implementation detail' of this particular exploit and not required to trigger the bug (see bug 1544386).

Comment 12

[Hayden Parker]

Our CISO Philip is planning on tweeting a little more information about the attack we saw, including IOCs, and plans to disclose that there is a separate sandbox escape that exists right now. Please let me know if there are any concerns with this.

Comment 13

[Al Billings [:abillings - ex-MoCo]]

(In reply to Hayden Parker from comment #12)

Our CISO Philip is planning on tweeting a little more information about the attack we saw, including IOCs, and plans to disclose that there is a separate sandbox escape that exists right now. Please let me know if there are any concerns with this.

Bugzilla is probably not an ideal method for discussing this. Emailing [e-mail] would be better. I think we'd prefer to not publicly discuss the sandbox escape until we have finalized our patch for the issue and shipped the fix in a release. It will draw further attention to the issue by potential hackers if discussed before this.

Comment 14

[Al Billings [:abillings - ex-MoCo]]

Discussion moved to security@ email.

Comment 15

[Andrew McCreight [:mccr8]]

We have bugs filed for the two sub problems, but I think it makes sense to mark this sec-critical.

Comment 16

[Andrew McCreight [:mccr8]]

Fixed by bug 1544386 and bug 1559858.

Comment 17

[Hayden Parker]

Hey team,

A couple questions.

So far we're only seeing this exploit code work on OSX. Can you confirm that the vulnerability does not impact windows users?

Second, in the getOffsets function of the exploit code I send over, I see a check for version 66 of Firefox. Was version 66 affected by this?

Thanks for all the help.

Comment 18

[Andrew McCreight [:mccr8]]

The actual exploit might only work on certain versions and OSes, but the two underlying flaws the exploit took advantage of look like they affected all versions at least back to 60, and probably further back, and all operating systems, so presumably some variant of the exploit could be made to work.