Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 599607 (CVE-2010-3777)

js_MakeArraySlow from 1.9.2 and 1.9.1 is GC-unsafe on 64-bit




JavaScript Engine
7 years ago
6 years ago


(Reporter: Igor Bukanov, Assigned: Igor Bukanov)


1.9.2 Branch

Firefox Tracking Flags

(status2.0 unaffected, blocking1.9.2 needed, status1.9.2 .13-fixed, blocking1.9.1 .17+, status1.9.1 .17-fixed)


(Whiteboard: [sg:critical?] impractical attack vector? fixed by bug 575024)



7 years ago
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

7 years ago
Forgot to set security-sensitive flag when submitting, sorry about that.
Group: core-security
status1.9.1: --- → wanted
status1.9.2: --- → wanted
status2.0: --- → unaffected
Whiteboard: [sg:critical?] impractical attack vector?
Don't we limit array length to 2^32-1, per ECMA?

Comment 3

7 years ago
(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.


7 years ago
Assignee: general → igor


7 years ago
OS: All → Linux

Comment 4

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

Comment 5

7 years ago
(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

7 years ago
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?
Depends on: 575024
Whiteboard: [sg:critical?] impractical attack vector? → [sg:critical?] impractical attack vector? fixed by bug 575024
blocking1.9.1: --- → needed
blocking1.9.2: --- → needed
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?
the patch for bug 575024 was checked in on the 1.9.2 branch by Reed, this should be fixed there.
Last Resolved: 7 years ago
status1.9.2: wanted → .13-fixed
Resolution: --- → FIXED
Alias: CVE-2010-3777
blocking1.9.1: needed → .17+

Comment 9

7 years ago
the patch for 191 from bug 575024 has landed (see bug 575024 comment 10), so this should fix the problem on 1.9.1.
status1.9.1: wanted → .17-fixed
Group: core-security
Group: core-security
Group: core-security
You need to log in before you can comment on or make changes to this bug.