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)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: bsterne, Assigned: bzbarsky)

References

Details

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

Attachments

(4 files)

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

<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>
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 FixSplinter 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 fixSplinter 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.
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.
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+
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.