Closed Bug 456896 (CVE-2008-5021) Opened 16 years ago Closed 16 years ago

[FIX]Crash [@ nsFrameManager::GetPrimaryFrameFor] with invalid input type (ZDI-CAN-390)

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bsterne, Assigned: bzbarsky)

References

Details

(Keywords: fixed1.8.1.18, verified1.9.0.4, Whiteboard: [sg:critical?])

Attachments

(4 files)

testcase crashes trunk
(deleted), text/html
Details
Backtrace from branch crash
(deleted), text/plain
Details
Fix
(deleted), patch
jst
: review+
jst
: superreview+
dveditz
: approval1.9.0.4+
Details | Diff | Splinter Review
1.8 branch fix
(deleted), patch
dveditz
: approval1.8.1.18+
asac
: approval1.8.0.next+
Details | Diff | Splinter Review
Attached file testcase crashes trunk (deleted) —
Cameron Hotchkies, via the TippingPoint Zero Day Initiative (ZDI), reported this crash to security@m.o. The crash appears to be exploitable, and I will attach a backtrace shortly. From the advisory: ---------- This vulnerability allows attackers to potentially execute arbitrary code on vulnerable installations of Mozilla Firefox. User interaction is required to exploit this vulnerability in that the target must visit a malicious page. The specific flaw exists when a DOM method on a specific HTML form object is called before the object itself has actually completed it's initialization. This will lead to a call of uninitialized data which can result in code execution under the context of the current user. This race condition is triggered by changing the type property of a 'file' input field to an invalid type before it actually gets rendered. This can be done inside the onload callback of an object. When the blur method for the input object is called, Firefox will make a method call to an uninitialized address during rendering. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>wushi0016</title> <script type='text/javascript'> function goodbye() { nodeList = document.getElementsByTagName("input"); testNode = nodeList.item(0); testNode.type = "yabba-dabba-do"; return testNode.blur(); } </script> </head> <body onload="goodbye()"> <input type="file" /> </body> </html>
Attached file Backtrace from branch crash (deleted) —
Whiteboard: [sg:critical?]
Component: Layout → Layout: Form Controls
QA Contact: layout → layout.form-controls
Doesn't crash for me on mozilla-central, Linux. If it also works for you on mozilla-central, then we should figure out what fixed it by binary-searching builds.
It crashes for me, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080922032349 Minefield/3.1b1pre
I crashed on mozilla-central, Linux. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080924114706 Minefield/3.1b1pre
OK, I see this on trunk. The relevant part is here: #12 0x02f7857d in nsFileControlFrame::SetFocus (this=0x163a6e8, aOn=0, aRepaint=0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/forms/nsFileControlFrame.cpp:256 256 content->SetFocus(PresContext()); (gdb) list 251 { 252 // Fix for Bug 6133 253 if (mTextFrame) { 254 nsIContent* content = mTextFrame->GetContent(); 255 if (content) { 256 content->SetFocus(PresContext()); 257 } 258 } 259 } 260 (gdb) p content $9 = (nsTypedSelection *) 0xb59b730 (gdb) p mTextFrame $10 = (nsNewFrame *) 0xdddddddd The callstack to this SetFocus call is: #13 0x031f8b21 in nsGenericHTMLElement::RemoveFocus (this=0x8180360, aPresContext=0x1660800) at /Users/bzbarsky/mozilla/debug/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:2914 #14 0x031ffd9e in nsGenericHTMLElement::SetElementFocus (this=0x8180360, aDoFocus=0) at /Users/bzbarsky/mozilla/debug/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:2879 #15 0x0322d807 in nsHTMLInputElement::Blur (this=0x8180360) at /Users/bzbarsky/mozilla/debug/mozilla/content/html/content/src/nsHTMLInputElement.cpp:1249 with the blur happening from JS.
So the basic problem is that in RemoveFocus we get the frame without flushing. At this point there is a pending reframe for that frame. Then we call SetFocus() on the frame. This calls SetFocus() on the content, which calls into the ESM SetContentState, which goes to SendFocusBlur(), which stats cheking whether things are focusable, which flushes frames. RemoveFocus should probably flush, I would think. It looks like the code has been like this ever since being first added in bug 250006.
Blocks: 250006
Oh, and the invalid input type is a red herring. Any type that is not "file" should do the trick.
Attached patch Fix (deleted) — — Splinter Review
Attachment #340346 - Flags: superreview?(jst)
Attachment #340346 - Flags: review?(jst)
Assignee: nobody → bzbarsky
Summary: Crash [@ nsFrameManager::GetPrimaryFrameFor] with invalid input type → [FIX]Crash [@ nsFrameManager::GetPrimaryFrameFor] with invalid input type
Attachment #340346 - Flags: superreview?(jst)
Attachment #340346 - Flags: superreview+
Attachment #340346 - Flags: review?(jst)
Attachment #340346 - Flags: review+
Pushed changeset dc6989cea2e5.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Attachment #340346 - Flags: approval1.9.0.4?
Comment on attachment 340346 [details] [diff] [review] Fix This applies to 1.9 branch.
Attached patch 1.8 branch fix (deleted) — — Splinter Review
Attachment #340376 - Flags: approval1.8.1.18?
Impressive turnaround on this, Boris. Many thanks.
Alias: ZDI-CAN-390
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x+
Flags: blocking1.9.0.4+
Flags: blocking1.8.1.18+
Investigating a report of someone on Twitter who says he's crashing regularly since the 3.0.2 update and the stack trace looks very similar to this. http://crash-stats.mozilla.com/report/index/ff0de4ba-8b0f-11dd-b829-001a4bd43ef6?p=1 Is this the same crash? Is it possible that this is a widespread crash?
> Is this the same crash? Sure looks like it, but this code didn't change in 3.0.2, so I wouldn't expect this to be new since the update.... > Is it possible that this is a widespread crash? Yes: it'll happen any time blur() is called while there is a pending style reresolve that can trigger a frame reconstruct.
Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080926033937 Minefield/3.1b1pre
Status: RESOLVED → VERIFIED
Comment on attachment 340346 [details] [diff] [review] Fix Approved for 1.9.0.4, a=dveditz for release-drivers
Attachment #340346 - Flags: approval1.9.0.4? → approval1.9.0.4+
Comment on attachment 340376 [details] [diff] [review] 1.8 branch fix Approved for 1.8.1.18, a=dveditz for release-drivers
Attachment #340376 - Flags: approval1.8.1.18? → approval1.8.1.18+
Checked in on both branches.
Keywords: fixed1.8.1.18, fixed1.9.0.4
This doesn't crash 2.0.0.17 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/2008082909 Firefox/2.0.0.17) when I try it. Is this exploitable in 2.x?
Verified for 1.9.0.4 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4pre) Gecko/2008102104 GranParadiso/3.0.4pre. I was able to crash 3.0.3 without issues with the testcase.
Keywords: fixed1.9.0.4 → verified1.9.0.4
According to Bsterne, this has not exhibited itself through a crash in 1.8.1 so we're just fixing the code there.
Attachment #340376 - Flags: approval1.8.0.15+
Comment on attachment 340376 [details] [diff] [review] 1.8 branch fix a=asac for 1.8.0
Flags: blocking1.8.0.15+
Attachment #340247 - Attachment is private: true
Alias: ZDI-CAN-390 → CVE-2008-5021
Summary: [FIX]Crash [@ nsFrameManager::GetPrimaryFrameFor] with invalid input type → [FIX]Crash [@ nsFrameManager::GetPrimaryFrameFor] with invalid input type (zdi-can-390)
Group: core-security
Summary: [FIX]Crash [@ nsFrameManager::GetPrimaryFrameFor] with invalid input type (zdi-can-390) → [FIX]Crash [@ nsFrameManager::GetPrimaryFrameFor] with invalid input type (ZDI-CAN-390)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: