Closed Bug 616009 (CVE-2011-0055) Opened 15 years ago Closed 15 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: 15 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: