599607 - (CVE-2010-3777) js_MakeArraySlow from 1.9.2 and 1.9.1 is GC-unsafe on 64-bit

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Igor Bukanov]

On 1.9.2 and 1.9.1 branches the dense array capacity can grow beyond JSID_INT_MAX (2**32 - 1) as the capacity limit is set to 2**word_size/sizeof(jsval). Thus on these branches with 64 bit CPU, when js_MakeArraySlow loops over all elements, it may reach indexes that goes beyond JSID_INT_MAX. For such indexes JS_ValueToId convert them into strings. The latter could trigger the last-ditch GC. That GC will collect JSScopeProperty instances that are added to the just created scope since the scope is not reachable through any object leading to a GC hazard.

In practice this can only be exploitable if one can allocate more than 8GB array which requires very high end hardware and patience to wait for an exploit to fill the array before killing the browser.

On the trunk the array capacity limit is set to 2*32/sizeof(jsval) or 2*29 so JS_ValueToId from makeDenseArraySlow cannot allocate any GC things. Still the implementation for the bug 569422 need to be aware of this as the proposed changes there allocates shapes as GC things leading to a possibility of the last-ditch GC for any array.

Comment 1

[Igor Bukanov]

Forgot to set security-sensitive flag when submitting, sorry about that.

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Don't we limit array length to 2^32-1, per ECMA?

Comment 3

[Igor Bukanov]

(In reply to comment #2)
> Don't we limit array length to 2^32-1, per ECMA?

Yes, but on 64 bit the bug happens before that and related to the possibility of having an array with length exceeding JSID_INT_MAX, 2**30 - 1.

Comment 4

[Robert Sayre]

when do you think you'll have a chance to fix this? I know you've got other bugs in the air?

Comment 5

[Igor Bukanov]

(In reply to comment #4)
> when do you think you'll have a chance to fix this? I know you've got other
> bugs in the air?

The fix should be trivial and I will have a patch tomorrow.

Comment 6

[Igor Bukanov]

The patch to fix is the one-liner from bug Bug 575024. How should I nominate it for branches given that that bug is not restricted but this one is?

Comment 7

[Daniel Veditz [:dveditz]]

We need a different patch for the 1.9.1 branch since the one in bug 575024 doesn't apply. Does the #define for MAX_DSLOTS_LENGTH32 from the 1.9.2 branch work on 1.9.1 (presumably with the extra -1 term), or is the fact that it's missing mean js objects have different limits on that branch?

Comment 8

[Daniel Veditz [:dveditz]]

the patch for bug 575024 was checked in on the 1.9.2 branch by Reed, this should be fixed there.

Comment 9

[Igor Bukanov]

the patch for 191 from bug 575024 has landed (see bug 575024 comment 10), so this should fix the problem on 1.9.1.