622015 - (CVE-2011-0056) JavaScript Atom Invalid Index Vulnerability -- iDefense [V-ikgwbx1hqs]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Reed Loden [:reed]]

Attachment: PoC

iDefense VCP Submission V-ikgwbx1hqs

12/29/2010

Mozilla Firefox JavaScript Atom Invalid Index Vulnerability



Description: 

Remote exploitation of a memory corruption vulnerability in Mozilla Organization's FireFox could allow an attacker to execute arbitrary code with the privileges of the current user.



The vulnerability occurs in the JavaScript engine (SpiderMonkey) of Mozilla FireFox. When compiling javascript, the Mozilla engine produces bytecode that is later interpreted in a virtual machine. Strings and other literals (so called atoms) are stored in an atom map. Opcodes that use values from the atom map take a 16 bit immediate constant operand that is used as an index in the atom map array. When more than 64k atoms are used, special handling is required because a 16 bit value would not suffice to address the desired atom. Therefore, the engine frames the opcode with an "indexbaseX" and a "resetbase0" opcode that move the atoms pointer forward and backward respectively. When an exception is thrown in between the indexbase and resetbase opcodes, the atoms pointer does not get reset and the exception object of the catch block is read from an invalid memory address. This results in an exploitable memory corruption vulnerability. 



Analysis: 

Exploitation of this vulnerability results in the execution of arbitrary code with the privileges of the user viewing the web page. To exploit this vulnerability, a targeted user must load a malicious webpage created by an attacker. An attacker typically accomplishes this via social engineering or injecting content into compromised, trusted sites. After the user visits the malicious web page, no further user interaction is needed.



In order to exploit this vulnerability, it is necessary control various structures at the location of the invalid reference. By performing a heap spray it is possible to populate memory with the needed structures and obtain reliable arbitrary code execution. 



Credit: 

Christian Holler

Comment 1

[Robert Sayre]

Word has it that Igor is the one to handle this. Let us know if this turns out to be wrong.

Comment 2

[Luke Wagner [:luke]]

Not blocking this bug, but it seems like we should reevaluate the space/time benefits of all this indexbase complexity.

Comment 3

[Igor Bukanov]

(In reply to comment #2)
> Not blocking this bug, but it seems like we should reevaluate the space/time
> benefits of all this indexbase complexity.

I am going to try 3-byte indexes and see how this affects interpreter-only benchmarks.

Comment 4

[Igor Bukanov]

Attachment: v1

Here is an untested work-in-progress.

Comment 5

[Igor Bukanov]

Attachment: v2

Here is another WIP - it still fails few tests during make check.

Comment 6

[Igor Bukanov]

The resulting patch for expanding the literal index to 3 bytes is too big to port it to branches. Apparently the macros to work with the bytecode do not abstract the literal index sufficiently to allow for a small and easy to test patch. So I will delegate that to the bug 622557 while focusing here on hopefully one-liner fix.

Comment 7

[Igor Bukanov]

A simpler test case that builds a function source with over 64K literals:

var src = "var a=[";
for(var i  = 0; i != 1e5; ++i)
    src += "'a"+i+"',";
src += "]; i = 'xyz';";
src += "try { x.y; return a; } catch(e) { return this[i]; }";

var x = { get y() { throw 0; }};
var xyz = 42;

assertEq(Function(src)(), 42);


It asserts/crashes in debug/optimized builds.

Comment 8

[Igor Bukanov]

Attachment: two-liner fix

The fix adds missing re-initialization of atoms.

Comment 9

[Brendan Eich [:brendan]]

Comment on attachment 500865 [details] [diff] [review]
two-liner fix

Need back-porting, should be easy.

/be

Comment 10

[Igor Bukanov]

http://hg.mozilla.org/tracemonkey/rev/61e3418e4223

Comment 11

[Igor Bukanov]

The bug is definitely critical

Comment 12

[Chris Leary [:cdleary] (not checking bugmail)]

http://hg.mozilla.org/mozilla-central/rev/61e3418e4223

Comment 13

[Reed Loden [:reed]]

Guys, can we get this on the branches?

Comment 14

[Christian Holler (:decoder)]

Please note that the particular PoC attached here is a shell PoC only and won't run in browser (it might even fail in the shell, it was tested with Ubuntu and the shell from Firefox 3.6.11 release). Exploitation in the browser works the same as in shell but requires more complicated heap spraying to work reliable.

I won't ever publish the working exploit for the browser.

Comment 15

[Christian Holler (:decoder)]

Fyi, successful exploitation in the shell looks like this:

 Program received signal SIGSEGV, Segmentation fault.
 0x08177853 in js_Interpret (cx=0x81ba9e0) at jsops.cpp:2208
 2208                        ok = ((JSFastNative) fun->u.n.native)(cx, argc, vp);
 (gdb) print fun->u.n.native
 $1 = (JSNative) 0xdeadbeef
 (gdb)

Comment 16

[Igor Bukanov]

Attachment: fix for 19[12]

The patch is a trivial backport to 1.9.2, here is a plain diff between the trunk and it:

4,7c4,7
< @@ -6805,7 +6805,6 @@ END_CASE(JSOP_ARRAYPUSH)
<          // Handle exceptions as if they came from the imacro-calling pc.
<          regs.pc = regs.fp->imacropc();
<          regs.fp->clearImacropc();
---
> @@ -3069,7 +3069,6 @@ js_Interpret(JSContext *cx)
>          // Handle other exceptions as if they came from the imacro-calling pc.
>          regs.pc = fp->imacpc;
>          fp->imacpc = NULL;
10d9
<  #endif
12c11,12
< @@ -6834,6 +6833,9 @@ END_CASE(JSOP_ARRAYPUSH)
---
>      JS_ASSERT((size_t)((fp->imacpc ? fp->imacpc : regs.pc) - script->code) < script->length);
> @@ -3092,6 +3091,9 @@ js_Interpret(JSContext *cx)

Comment 17

[Igor Bukanov]

Comment on attachment 504464 [details] [diff] [review]
fix for 19[12]

The 192 patch applies as-is to 191.

Comment 18

[LegNeato]

Comment on attachment 504464 [details] [diff] [review]
fix for 19[12]

a=LegNeato for 1.9.2.14 and 1.9.1.17

Comment 19

[Igor Bukanov]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2e5604a977d0

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4e5edc8a6382

Comment 21

[Al Billings [:abillings - ex-MoCo]]

Verified crash in 1.9.1.16 with PoC and fix in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.17pre) Gecko/20110121 Shiretoko/3.5.17pre ( .NET CLR 3.5.30729).

Same with 1.9.2.13 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14pre) Gecko/20110121 Namoroka/3.6.14pre ( .NET CLR 3.5.30729).

Comment 22

[Mike Hommey [:glandium]]

Attachment: Fix for 1.9.0

Would that be enough for 1.9.0 ? (It looks like so ; at least the testcase doesn't crash anymore)

Comment 23

[Igor Bukanov]

Comment on attachment 512152 [details] [diff] [review]
Fix for 1.9.0

Please use diff -U8 the next time you attach the patch for a review to get more context.