1346951 - WL: kidicarus investigation

Status: RESOLVED WORKSFORME

(mozilla.org :: Security Assurance, task)

Description

[Daniel Veditz [:dveditz]]

Attachment: utility.js (minimized)

Wikileaks sent us an archive with some javascript files in them, without any documents contextualizing them. One of the directories was "kidicarus.0" and contained the single javascript file utility.js (minimized). From the name I'm assuming this is part of something else and does not demonstrate a vulnerability, but we should investigate.

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: utility.js (reformatted)

Here's utility.js pretty printed which is a bit more readable

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: utility.js (added some comments and symbol renaming)

Added some comments that might help people work through it. There are version-specific constants in the file that show it working against Firefox 10 through 16.0.2. There's always a question whether we fixed a bug at that point or if this is an OLD data dump with a bug active after that point (see bug 1346963 for example), but in this case the script uses E4X and in Firefox 17 we disabled E4X for content (bug 778851).

There is a lot of other stuff going on in this file: is there more than just an E4X issue? The payload section is obviously running with chrome privilege, and equally obviously they didn't have that when they start their exploit or they wouldn't have to bother with all the cryptic object and array manipulation.

Comment 3

[Daniel Veditz [:dveditz]]

Adding Bobby who might have insight about the privilege escalation.

Comment 4

[Kris Maglione [:kmag]]

I'm pretty sure this wouldn't be exploitable without E4X.

I can't be certain of all the details without deciphering this and looking at the source for a version that this targets, but it looks like this relies on flaws in the implementation of the E4X function namespace. It seems to be assigning a specially-crafted array buffer to a property, and then trying to use it as a function. I'd guess that E4X made unsafe assumptions about the types of the objects stored in those properties, and tried to interpret non-function things as functions.

I don't see anything else particularly suspicious, aside from this:

function r() {
  var a = this.i(),
    b = a.d,
    a = a.R;
  this.w = {};
  this.w.length = a / b;
  this.w.__defineGetter__("0", function() {
    Throw(0)
  });
  this.Q = function(a) {
    return a
  }
}
r.prototype.N = function() {
  try {
    Array.prototype.map.call(this.w, this.Q)
  } catch (a) {}
  try {
    Array.prototype.map.call(this.w, this.Q)
  } catch (b) {}
};

But that doesn't seem to do anything particularly interesting in current versions of Spidermonkey.

Comment 5

[Kris Maglione [:kmag]]

Also worth noting that in all of the sections of code like this:

  return new p({
    d: 0,
    R: 1
  }, {
    "Win32, Linux i686, Linux x86_64, MacIntel": {
      "10.0": [8, 134217728],
      "10.0.1": [8, 134217728],
      "10.0.2": [8, 134217728],
      "10.0.3": [8, 134217728],
      "10.0.4": [8, 134217728],
      "11.0": [8, 134217728],
      "12.0": [8, 134217728],
      "13.0": [8, 134217728],
      "13.0.1": [8, 134217728],
      "14.0.1": [8, 134217728],
      "15.0": [8, 134217728],
      "15.0.1": [8, 134217728],
      "16.0": [8, 134217728],
      "16.0.1": [8, 134217728],
      "16.0.2": [8, 134217728]
    }
  })

The named properties in the first object get the values of the array index in the matching version. So {d: 8, R: 134217728} in this case, in Firefox 10-16. None of these objects contain a version newer than 16.0.2 (which incidentally means that every supported version supports E4X), so this code won't work on any newer version than that.

Comment 6

[Daniel Veditz [:dveditz]]

E4X was disabled in web content in Firefox 17 (bug 778851) and removed entirely from the tree in Firefox 21 (bug 788293).