Closed Bug 616009 (CVE-2011-0055) Opened 14 years ago Closed 14 years ago

JSON.stringify Dangling Pointer Remote Code Execution Vulnerability (ZDI-CAN-971)

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -
status2.0 --- unaffected
blocking1.9.2 --- .14+
status1.9.2 --- .14-fixed
blocking1.9.1 --- .17+
status1.9.1 --- .17-fixed

People

(Reporter: reed, Assigned: igor)

References

Details

(4 keywords, Whiteboard: [sg:critical])

Attachments

(2 files)

Attached file PoC
ZDI-CAN-971: Mozilla Firefox JSON.stringify Dangling Pointer Remote Code Execution Vulnerability

-- CVSS ----------------------------------------------------------------
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)

-- ABSTRACT ------------------------------------------------------------

TippingPoint has identified a vulnerability affecting the following
products:

    Mozilla Firefox 3.6.x

-- VULNERABILITY DETAILS -----------------------------------------------

This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of Firefox. User interaction is required to
exploit this vulnerability in that the target must visit a malicious
page or open a malicious file.

The specific flaw exists within js3250.dll. In the JSON.stringify() call
chain js_HasOwnProperty() is called with an invalid pointer. The pointer
becomes invalid due to being unrooted and garbage collection occurring.
Dereferecing of this pointer allows a remote attacker to execute
arbitrary code in the context of the user running the browser.

Version(s)  tested: Firefox 3.6.10
Platform(s) tested: Windows XP SP3 x86

There is a GC hazard in function |JO|. One can see that |obj| is rooted
only at |vp[0]|. Then, if there is no replacer object associated or
replacer is an array, |js_ValueToIterator| is called returning iterator
instance at
|keySource|, where |keySource| is a pointer == |vp|. Thus |obj| becomes
unrooted while still being used as an argument in several functions'
invocations along the |JO| body.

POC triggers a jump to an invalid address in ecx, below:

0:000> ub 0033e2a1  
js3250!js_LookupProperty+0x497f:
0033e28f 70dd            jo      js3250!js_LookupProperty+0x495e
(0033e26e)
0033e291 54              push    esp
0033e292 2478            and     al,78h
0033e294 e9dcf0ffff      jmp     js3250!js_LookupProperty+0x3a65
(0033d375)
0033e299 8b542438        mov     edx,dword ptr [esp+38h]
0033e29d 50              push    eax
0033e29e 52              push    edx
0033e29f ffd1            call    ecx

Call Stack:

ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be
wrong.
0012ea70 0033e2a1 <Unloaded_ta.dll>+0x14f859f
0012eca4 00338556 js3250!js_LookupProperty+0x4991
0012ed48 0032cfd3 js3250!js_Invoke+0x286
0012ed78 0030ea07 js3250!JS_CloneFunctionObject+0x1493
0012ee2c 0030f8ff js3250!JS_CallFunctionValue+0x27
0012eef0 00370e96 js3250!js_AllocStack+0x24f
0012f02c 0033bbaa js3250!JS_NewArrayObject+0x316
0012f26c 00338556 js3250!js_LookupProperty+0x229a
0012f310 0032cfd3 js3250!js_Invoke+0x286
0012f340 0030ea07 js3250!JS_CloneFunctionObject+0x1493
0012f3e4 100be05a js3250!JS_CallFunctionValue+0x27
0012f590 1009635d xul!gfxRect::Condition+0x28a
0012f680 101066c1 xul!gfxWindowsFontGroup::MakeTextRun+0x1130c
0012f6e0 10106b71 xul!NS_Free_P+0x3f1
0012f728 1010ed88 xul!NS_Free_P+0x8a1
0012f7b4 1007482b xul!NS_Free_P+0x8ab8
0012f81c 10091ba7 xul!gfxWindowsSurface::gfxWindowsSurface+0x6c1b
0012f9b0 1011217e xul!gfxWindowsFontGroup::MakeTextRun+0xcb56
0012f9b4 100f11ab xul!NS_CycleCollectorSuspect2_P+0x15ee
0012f9d4 1006c81e xul!gfxRect::gfxRect+0x101b
0:000> ub 0033e2a1  

-- CREDIT --------------------------------------------------------------

This vulnerability was discovered by:
    * regenrecht
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
status1.9.1: --- → ?
status1.9.2: --- → ?
Tested on Linux...

On trunk, PoC loads fine with no issues.
On 3.6.x, PoC hangs browser (throws slow script warning repeatedly).
This isn't DOM.

On trunk, I would assume stack scanning is why this works.
Assignee: nobody → general
Component: DOM → JavaScript Engine
QA Contact: general → general
The stack scanner in 2.0 should find obj and keep it alive (I don't crash with 4.0b7 on this test case).
blocking2.0: ? → ---
We could probably backport the stack scanner to 3.6 with reasonable effort and pretty limited risk.
Keywords: crash
Whiteboard: [sg:critical?]
While we talk about backporting the stack scanner and argue over how much time that will take and at what risk, can we just locally fix the rooting problem in this code?
blocking1.9.1: ? → .17+
blocking1.9.2: ? → .14+
Keywords: testcase
Sayre: please assign to the right person on your team.
Assignee: general → sayrer
Can we get some action on this externally-reported security bug? An actual assignee would be great.
Its assigned to sayrer.
Attached patch untested patchSplinter Review
Attachment #501345 - Flags: review?
Attachment #501345 - Flags: review? → review?(sayrer)
The patch is untested and based on regenrecht's analysis. Sayrer, want to give it a spin and land it? Thanks
Whiteboard: [sg:critical?] → [sg:critical]
(In reply to comment #11)
> The patch is untested and based on regenrecht's analysis. Sayrer, want to give
> it a spin and land it? Thanks

testing.
Comment on attachment 501345 [details] [diff] [review]
untested patch

I get an immediate segfault with the PoC on 1.9.2.

This patch fixes it.
Attachment #501345 - Flags: review?(sayrer) → review+
Attachment #501345 - Flags: approval1.9.2.14?
Attachment #501345 - Flags: approval1.9.1.17?
Can we add a test?
This bug is a dup of the bug 619255 that have approved patches. I wish I would new about this bug before spending time to check JSON code after Gal made that post about back-porting conservative stack scanner to 1.9.*
Yeah, patches are basically identical. Took 10 seconds to make this patch, no big loss to dup them. Igor, all yours. Are you ready to land your fix?
(In reply to comment #16)
> Yeah, patches are basically identical. Took 10 seconds to make this patch, no
> big loss to dup them. Igor, all yours. Are you ready to land your fix?

Yes, I can land on the branches.
blocking2.0: --- → -
Comment on attachment 501345 [details] [diff] [review]
untested patch

clearing approval requests given the already-approved versions in bug 619255.
Attachment #501345 - Flags: approval1.9.2.14?
Attachment #501345 - Flags: approval1.9.1.17?
(In reply to comment #14)
> Can we add a test?

See bug 619255 comment 0 - that should be landed when we clear the security status of this bug.
Assignee: sayrer → igor
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Verified crashes with PoC with 1.9.1.16 and 1.9.2.13.

Verified crash in previous day's nightlies and that it is fixed in today's.

I used: 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.17pre) Gecko/20110107 Shiretoko/3.5.17pre

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14pre) Gecko/20110107 Namoroka/3.6.14pre
Alias: ZDI-CAN-971 → CVE-2011-0055
Attachment #494528 - Attachment is private: true
Group: core-security
Attachment #494528 - Attachment is private: false
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: