On FF35, non-extensible objects can be extended

[GoogleCodeExporter]

This is reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1125389 as a 
non-disclosed bug I was given permission to see and share in a limited manner.  
It was fixed on 1/29/2015 and propagated back through FF36. It will not be 
propagated back to FF35, so it remains vulnerable.

Comment 6 shows a case that will demonstrate the bug in the FF35 browser:

function Obj() {
    this.x = 0;
    Object.preventExtensions(this);
}
var i = 0;
function test() {
    var A = new Obj();
    while (true) {
        i++;
        if (Object.isExtensible(A)) {
            throw new Error("Shouldn't get here");
        }
    }
    A.length1 = X;
}
try {
    test();
} catch (e) {
    console.log(e, 'iterations: ' + i);
}

Original issue reported on code.google.com by erights on 15 Feb 2015 at 5:13

[GoogleCodeExporter]

At the time of this writing, FF35 is the current release. FF36 is expected to 
become the new release on 2/23. There is no known way to repair so we can both 
run and be safe. But we can detect and refuse to run on any browser with this 
bug. 

Should this bug become public, or there be any evidence that it is being 
exploited, we should release such detection and refusal immediately. In the 
meantime, I suggest we wait until FF36 is released, and then proceed to roll 
out this detection and refusal.

Original comment by erights on 15 Feb 2015 at 5:16

[GoogleCodeExporter]

Started at https://codereview.appspot.com/202040043

Original comment by erights on 15 Feb 2015 at 5:33

[GoogleCodeExporter]

I just added the following comment to the undisclosed mozilla bug at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1125389

Google's official policy https://support.google.com/a/answer/33864 is that the 
present and immediately previous major releases of FF, IE, and Safari are 
supported. IIUC, the release of FF36 is about a week away, and the release of 
FF37 about 6 weeks after that.

I have an undisclosed CL at https://codereview.appspot.com/202040043/ that 
cannot be revealed without disclosing this bug. However, since this bug seems 
fatal, I don't know the triggering conditions, nor any workarounds or 
mitigations, once this CL is submitted, Caja and SES will merely detect the 
existence of the bug and refuse to run, so it will stop working on FF35. Should 
this bug become public or we see evidence that it is being exploited, we would 
need to submit this CL immediately.

If we did have a workaround we could add as a repair to 
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/se
s/repairES5.js , then we could avoid an unpleasant situation. Curiously, I do 
have one weak bit of evidence that this bug may be repairable:

When I run the unsubmitted SES self test from that secret CL, when it runs the 
test a second time it, the symptoms repeatedly disappear. However, since I 
don't understand why, or what triggers this apparent disappearance, I have the 
SES self test conservatively assume that the bug can still be exploited.

Any ideas for a potential mitigation or workaround?

Original comment by erights on 15 Feb 2015 at 6:37

[GoogleCodeExporter]

Original comment by erights on 15 Feb 2015 at 6:45

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

Original comment by erights on 15 Feb 2015 at 6:56

• Added labels: Component-SES
• Removed labels: Component-Other

[GoogleCodeExporter]

Question: Do we have Caja users at Google that uses SES and are not configured 
to fall back to ES5/3 if SES fails to initialize? If not, it would be much less 
painful on our FF35 users. (Though I would still like to wait until FF36 is 
released if we can.)

What do we know about SES users outside Google? How should we handle such 
responsible disclosure issues with them?

Original comment by erights on 15 Feb 2015 at 9:31

[GoogleCodeExporter]

Great news! We should be able to repair this, so we don't need to break FF35. 
In the private Mozilla bug thread I asked about possible mitigations or 
workarounds. Just now, in comment 28:

(In reply to Till Schneidereit [:till] from comment #27)
> Brian, is there anything that content script could do to prevent this bug
> from occurring?

Yes, there are several ways.  This bug only affects objects created by calling 
'new Foo()' on some script Foo.  If the constructor has been called more than 
20 times before preventing extensions then the bug won't impact anything.  If 
the object which preventExtensions is called on has any properties which are 
non-configurable or non-writable then the bug won't impact anything (so calling 
seal() or freeze() on an object with at least one property shouldn't be able to 
trigger this bug)

Original comment by erights on 16 Feb 2015 at 12:51

[GoogleCodeExporter]

In light of this, I will not submit https://codereview.appspot.com/202040043/ 
until it has a working repair for FF35, or until I give up on that plan.

Original comment by erights on 16 Feb 2015 at 12:52

[GoogleCodeExporter]

Original comment by erights@google.com on 24 Feb 2015 at 1:10

• Changed state: Pending

[GoogleCodeExporter]

Fixed in Caja r5717 by
https://codereview.appspot.com/202040043/
https://codereview.appspot.com/202030043/
https://codereview.appspot.com/214110043/

Original comment by erights on 13 Mar 2015 at 7:58

• Changed state: Fixed
• Removed labels: Private