1346972 - WL: stackup.1 investigation

Status: RESOLVED DUPLICATE of bug 983344

(mozilla.org :: Security Assurance, task)

Description

[Daniel Veditz [:dveditz]]

Attachment: main.js

Wikileaks sent us two javascript files in a directory called "stackup.1". They are devoid of web page context so hopefully the vulnerability is self contained.

Note that the Wikileaks dump might be old. Devoid of the messaging context (Confluence, apparently) we don't know what versions this exploit targeted or how long ago this was developed.

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: worker.js

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: main.js (pretty printed)

There's a boatload of parseFloat in the middle here that might be a clue, and at the end they've clearly escalated to a privileged context (calling ctypes and FileUtils using Components.utils).

There are a bunch of objects with what look like per-version values hanging off strings like "18.0" and "22.0". Could be we fixed it after Firefox 22, or maybe these are just old files and they hadn't updated the params to make the exploit work on later versions.

Comment 3

[Daniel Veditz [:dveditz]]

Attachment: worker.js (pretty printed)

Comment 4

[Daniel Veditz [:dveditz]]

Some of this code is similar to the kidicarus one, clearly a set of tricks that work for multiple vulns. Maybe something we can break even if the underlying vuln here was squashed?

Which, btw, we don't know for sure it is -- this is apparently an old dump and the exploit needs to be tested on Firefox 18-22, but that doesn't mean the vuln was fixed soon after that. The other stackup bug wasn't fixed until Firefox 28.

Comment 5

[Jan de Mooij [:jandem]]

I can investigate tomorrow if nobody beats me to it.

Typed arrays + workers make me wonder if this could be related to detached/neutered TAs, but that's just a very wild guess.

Comment 6

[Daniel Veditz [:dveditz]]

One of the other ones we got certainly was. Would it be worth just testing this and see what it does in an old Firefox 22?

Comment 7

[Steve Fink [:sfink] [:s:]]

It's definitely exploiting the same neutering/detaching bug as bug 1346963. And the version tables look very very similar as well, which makes me think there's some shared code. But there are a couple of other funky things that are new: the sequence of many parseFloat calls, and the sync XHR.

function n is a slightly different version of epf.vuln.CopyFromArray from https://bug1346963.bmoattachments.org/attachment.cgi?id=8846827&t=7BiMCot0GejB6fcmCFDi2e (there's only one 5 at the end instead of two.)


The parseFloat stuff looks like this:

        t();
        for (I = 0; I < u.p; I++) P[I].length -= (u.l - 8192) / u.b;
        var c = a.data;
        (c);
        4 !==
          c[0] && (U.onmessage = f, U.terminate(), d(f));
        t();

t() calls the v() twice. v() calls parseFloat exactly 128 times. I don't know if that's for some effect, or to create an in-memory pattern of the right size?

This is all in an onmessage callback for an event stored in a. The code implements a state machine on message events. The messages are arrays with an integer state in the 0th element. The 4 here is probably the same as in the epf.vuln thing:

/**
 * Constants identifying the messages sent between the worker and the parent
 */

/** @const */ epf.vuln.CopyFromArray.WORKER_INIT            = 1;
/** @const */ epf.vuln.CopyFromArray.WORKER_READY           = 2;
/** @const */ epf.vuln.CopyFromArray.WORKER_ARRAY_BUFFER    = 3;
/** @const */ epf.vuln.CopyFromArray.PARENT_ARRAY_BUFFER    = 4;
/** @const */ epf.vuln.CopyFromArray.AFTER_FIRST_OVERWRITE  = 5;
/** @const */ epf.vuln.CopyFromArray.AFTER_SECOND_OVERWRITE = 6;

Comment 8

[Steve Fink [:sfink] [:s:]]

At any rate, I would guess that the only vulnerability used here is the ArrayBuffer detachment stuff, abstracted out into read/write arbitrary memory functions. I would guess that the remainder of the weirdness is what they do to make use of those.

Comment 9

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

So this bug still affects us?

Comment 10

[Steve Fink [:sfink] [:s:]]

(In reply to Al Billings [:abillings] from comment #9)
> So this bug still affects us?

No. Fixed in bug 983344. It looks like these bugs are getting duped to that, but in case someone thinks there's more here to look at, I won't make that call. But I am satisfied that this is just bug 983344 again, and in fact uses the epf.vuln library from bug 1346963 (albeit a slightly different version.)

Comment 12

[Daniel Veditz [:dveditz]]

We're satisfied that this is essentially a minimized form of stackup.0 (bug 1346963) with some of the epf framework incorporated directly.