Bug 456896 (CVE-2008-5021)

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

VERIFIED FIXED

Status

()

Core
Layout: Form Controls
VERIFIED FIXED
9 years ago
6 years ago

People

(Reporter: bsterne, Assigned: bz)

Tracking

({fixed1.8.1.18, verified1.9.0.4})

Trunk
x86
All
fixed1.8.1.18, verified1.9.0.4
Points:
---
Bug Flags:
blocking1.9.0.4 +
wanted1.9.0.x +
blocking1.8.1.18 +
wanted1.8.1.x +
blocking1.8.0.next +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical?])

Attachments

(4 attachments)

(Reporter)

Description

9 years ago
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">

<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>
(Reporter)

Comment 1

9 years ago
Created attachment 340246 [details]
Backtrace from branch crash
(Reporter)

Updated

9 years ago
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
(Reporter)

Comment 5

9 years ago
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.
Created attachment 340346 [details] [diff] [review]
Fix
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

Updated

9 years ago
Attachment #340346 - Flags: superreview?(jst)
Attachment #340346 - Flags: superreview+
Attachment #340346 - Flags: review?(jst)
Attachment #340346 - Flags: review+
Pushed changeset dc6989cea2e5.
Status: NEW → RESOLVED
Last Resolved: 9 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.
Created attachment 340376 [details] [diff] [review]
1.8 branch fix
Attachment #340376 - Flags: approval1.8.1.18?
(Reporter)

Comment 13

9 years ago
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+

Comment 14

9 years ago
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.

Updated

9 years ago
Attachment #340376 - Flags: approval1.8.0.15+

Comment 23

9 years ago
Comment on attachment 340376 [details] [diff] [review]
1.8 branch fix

a=asac for 1.8.0

Updated

9 years ago
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.