Last Comment Bug 599607 - (CVE-2010-3777) js_MakeArraySlow from 1.9.2 and 1.9.1 is GC-unsafe on 64-bit
: js_MakeArraySlow from 1.9.2 and 1.9.1 is GC-unsafe on 64-bit
[sg:critical?] impractical attack vec...
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: 1.9.2 Branch
: x86_64 Linux
-- normal (vote)
: ---
Assigned To: Igor Bukanov
: Jason Orendorff [:jorendorff]
Depends on: 575024
  Show dependency treegraph
Reported: 2010-09-25 05:47 PDT by Igor Bukanov
Modified: 2011-03-28 16:32 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Igor Bukanov 2010-09-25 05:47:25 PDT
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 User image Igor Bukanov 2010-09-25 05:49:03 PDT
Forgot to set security-sensitive flag when submitting, sorry about that.
Comment 2 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2010-09-27 23:53:44 PDT
Don't we limit array length to 2^32-1, per ECMA?
Comment 3 User image Igor Bukanov 2010-09-28 01:19:14 PDT
(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 User image Robert Sayre 2010-10-12 14:16:28 PDT
when do you think you'll have a chance to fix this? I know you've got other bugs in the air?
Comment 5 User image Igor Bukanov 2010-10-12 14:31:41 PDT
(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 User image Igor Bukanov 2010-10-13 06:05:27 PDT
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 User image Daniel Veditz [:dveditz] 2010-11-18 20:02:34 PST
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 User image Daniel Veditz [:dveditz] 2010-11-19 10:17:43 PST
the patch for bug 575024 was checked in on the 1.9.2 branch by Reed, this should be fixed there.
Comment 9 User image Igor Bukanov 2011-01-19 03:26:20 PST
the patch for 191 from bug 575024 has landed (see bug 575024 comment 10), so this should fix the problem on 1.9.1.

Note You need to log in before you can comment on or make changes to this bug.