Closed Bug 1346972 Opened 3 years ago Closed 3 years ago
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.
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.
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.
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?
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 && (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;
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.
So this bug still affects us?
(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.)
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: CVE-2014-1514
We're satisfied that this is essentially a minimized form of stackup.0 (bug 1346963) with some of the epf framework incorporated directly.
Group: infra, mozilla-employee-confidential, core-security, infrasec
You need to log in before you can comment on or make changes to this bug.