Last Comment Bug 456896 - (CVE-2008-5021) [FIX]Crash [@ nsFrameManager::GetPrimaryFrameFor] with invalid input type (ZDI-CAN-390)
: [FIX]Crash [@ nsFrameManager::GetPrimaryFrameFor] with invalid input type (ZD...
: fixed1.8.1.18, verified1.9.0.4
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (TPAC)
Depends on:
Blocks: 250006
  Show dependency treegraph
Reported: 2008-09-24 16:29 PDT by Brandon Sterne (:bsterne)
Modified: 2011-08-05 23:34 PDT (History)
8 users (show)
dveditz: blocking1.9.0.4+
dveditz: wanted1.9.0.x+
dveditz: blocking1.8.1.18+
dveditz: wanted1.8.1.x+
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase crashes trunk (608 bytes, text/html)
2008-09-24 16:29 PDT, Brandon Sterne (:bsterne)
no flags Details
Backtrace from branch crash (6.81 KB, text/plain)
2008-09-24 16:29 PDT, Brandon Sterne (:bsterne)
no flags Details
Fix (851 bytes, patch)
2008-09-25 09:52 PDT, Boris Zbarsky [:bz] (TPAC)
jst: review+
jst: superreview+
dveditz: approval1.9.0.4+
Details | Diff | Splinter Review
1.8 branch fix (854 bytes, patch)
2008-09-25 11:35 PDT, Boris Zbarsky [:bz] (TPAC)
dveditz: approval1.8.1.18+
Details | Diff | Splinter Review

Description Brandon Sterne (:bsterne) 2008-09-24 16:29:05 PDT
Created attachment 340245 [details]
testcase crashes trunk

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">



        <meta http-equiv="Content-Type" content="text/html;


        <script type='text/javascript'>

            function goodbye() {

                nodeList = document.getElementsByTagName("input");

                testNode = nodeList.item(0);

                testNode.type = "yabba-dabba-do";

                return testNode.blur();




    <body onload="goodbye()">

        <input type="file" />


Comment 1 Brandon Sterne (:bsterne) 2008-09-24 16:29:38 PDT
Created attachment 340246 [details]
Backtrace from branch crash
Comment 3 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2008-09-24 20:55:54 PDT
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.
Comment 4 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-09-25 02:57:48 PDT
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
Comment 5 Brandon Sterne (:bsterne) 2008-09-25 09:19:16 PDT
I crashed on mozilla-central, Linux.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080924114706 Minefield/3.1b1pre
Comment 6 Boris Zbarsky [:bz] (TPAC) 2008-09-25 09:38:40 PDT
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     }
(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.
Comment 7 Boris Zbarsky [:bz] (TPAC) 2008-09-25 09:48:24 PDT
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.
Comment 8 Boris Zbarsky [:bz] (TPAC) 2008-09-25 09:51:14 PDT
Oh, and the invalid input type is a red herring.  Any type that is not "file" should do the trick.
Comment 9 Boris Zbarsky [:bz] (TPAC) 2008-09-25 09:52:09 PDT
Created attachment 340346 [details] [diff] [review]
Comment 10 Boris Zbarsky [:bz] (TPAC) 2008-09-25 11:33:05 PDT
Pushed changeset dc6989cea2e5.
Comment 11 Boris Zbarsky [:bz] (TPAC) 2008-09-25 11:34:33 PDT
Comment on attachment 340346 [details] [diff] [review]

This applies to 1.9 branch.
Comment 12 Boris Zbarsky [:bz] (TPAC) 2008-09-25 11:35:18 PDT
Created attachment 340376 [details] [diff] [review]
1.8 branch fix
Comment 13 Brandon Sterne (:bsterne) 2008-09-25 12:59:05 PDT
Impressive turnaround on this, Boris.  Many thanks.
Comment 14 Asa Dotzler [:asa] 2008-09-25 17:34:29 PDT
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.

Is this the same crash? Is it possible that this is a widespread crash?
Comment 15 Boris Zbarsky [:bz] (TPAC) 2008-09-25 18:07:12 PDT
> 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.
Comment 16 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-09-26 07:22:14 PDT
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080926033937 Minefield/3.1b1pre
Comment 17 Daniel Veditz [:dveditz] 2008-09-29 11:42:34 PDT
Comment on attachment 340346 [details] [diff] [review]

Approved for, a=dveditz for release-drivers
Comment 18 Daniel Veditz [:dveditz] 2008-09-29 11:42:45 PDT
Comment on attachment 340376 [details] [diff] [review]
1.8 branch fix

Approved for, a=dveditz for release-drivers
Comment 19 Boris Zbarsky [:bz] (TPAC) 2008-10-07 08:26:19 PDT
Checked in on both branches.
Comment 20 Al Billings [:abillings] 2008-10-21 14:14:48 PDT
This doesn't crash (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008082909 Firefox/ when I try it. Is this exploitable in 2.x?
Comment 21 Al Billings [:abillings] 2008-10-21 15:43:36 PDT
Verified for with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2008102104 GranParadiso/3.0.4pre. I was able to crash 3.0.3 without issues with the testcase.
Comment 22 Al Billings [:abillings] 2008-10-28 13:45:34 PDT
According to Bsterne, this has not exhibited itself through a crash in 1.8.1 so we're just fixing the code there.
Comment 23 Alexander Sack 2008-11-10 09:20:01 PST
Comment on attachment 340376 [details] [diff] [review]
1.8 branch fix

a=asac for 1.8.0

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