Closed Bug 649079 (CVE-2011-3664) Opened 13 years ago Closed 13 years ago

firefox crashes when loading npapi plugin OOP and mimetype is set before injection into the dom [@ nsPluginInstanceOwner::GetPluginPortFromWidget ]


(Core Graveyard :: Plug-ins, defect)

2.0 Branch
Not set


(firefox5 affected, firefox6- affected, firefox7 affected, firefox8- affected, firefox9 fixed, firefox10 fixed, status1.9.2 unaffected)

Tracking Status
firefox5 --- affected
firefox6 - affected
firefox7 --- affected
firefox8 - affected
firefox9 --- fixed
firefox10 --- fixed
status1.9.2 --- unaffected


(Reporter: richard, Assigned: jaas)




(Keywords: crash, crashreportid, Whiteboard: [sg:high][qa!])

Crash Data


(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0

When I create an object using document.createElement("object") and set the type before appending the element into the DOM, firefox crashes.  If I disable 64 bit ipc the issue goes away.  This issue can be easily reproduced by building FBTestPlugin from the FireBreath master ( and using the revision of test.html I referenced in the URL field of this bug.

To be clear, it is Firefox that crashes, not the plugin process; it is possible that this is due to something that the plugin is doing, but as it doesn't occur on Safari (32 or 64 bit), Chrome, or Firefox w/out ipc, this seems like a Firefox bug.

Reproducible: Always

Steps to Reproduce:
1. Download FireBreath (ideally using git), install cmake 2.8.4
2. run ./ examples from the firebreath website
3. open buildex/FireBreath.xcodeproj in xcode and build it
4. copy buildex/projects/FBTestPlugin/Debug/FBTestPlugin.plugin to ~/Library/Internet Plugins/
5. download
5. Open Firefox 4 on Mac OS X 10.6 in 64 bit mode and open test.html

It will crash.
Actual Results:  
It crashes. see

Crash ID: de472a68-35cf-42f7-a1fd-b2a472110411
Component: General → Extension Compatibility
Keywords: crash, crashreportid
QA Contact: general → extension.compatibility
Summary: firefox crashes when loading npapi plugin OOP and mimetype is set before injection into the dom → firefox crashes when loading npapi plugin OOP and mimetype is set before injection into the dom [@ nsPluginInstanceOwner::GetPluginPortFromWidget ]
Version: unspecified → 4.0 Branch
Component: Extension Compatibility → Plug-ins
Product: Firefox → Core
QA Contact: extension.compatibility → plugins
Version: 4.0 Branch → 2.0 Branch
Signature	nsPluginInstanceOwner::GetPluginPortFromWidget
UUID	de472a68-35cf-42f7-a1fd-b2a472110411
Time 	2011-04-11 11:28:04.6556
Uptime	16
Last Crash	89 seconds before submission
Install Age	1785452 seconds (3.0 weeks) since version was first installed.
Product	Firefox
Version	4.0
Build ID	20110318052756
Branch	2.0
OS Version	10.6.7 10J3250
CPU	amd64
CPU Info	family 6 model 42 stepping 7
Crash Reason	EXC_BAD_ACCESS / 0x0000000d
Crash Address	0x0
User Comments	
App Notes 	Renderers: 0x21b00,0x24300,0x20400GL Context? GL Context+
GL Layers? GL Layers+
Processor Notes 	
EMCheckCompatibility	False
Bugzilla - Report this Crash
Related Bugs

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	XUL 	nsPluginInstanceOwner::GetPluginPortFromWidget 	layout/generic/nsObjectFrame.cpp:6575
1 	XUL 	nsObjectFrame::CallSetWindow 	layout/generic/nsObjectFrame.cpp:1212
2 	XUL 	nsPluginHost::DoInstantiateEmbeddedPlugin 	modules/plugin/base/src/nsPluginHost.cpp:1109
3 	XUL 	nsObjectFrame::InstantiatePlugin 	layout/generic/nsObjectFrame.cpp:1135
4 	XUL 	nsObjectFrame::Instantiate 	layout/generic/nsObjectFrame.cpp:2710
5 	XUL 	nsObjectLoadingContent::Instantiate 	content/base/src/nsObjectLoadingContent.cpp:1894
6 	XUL 	nsObjectLoadingContent::EnsureInstantiation 	content/base/src/nsObjectLoadingContent.cpp:917
7 	XUL 	nsHTMLPluginObjElementSH::GetPluginInstanceIfSafe 	dom/base/nsDOMClassInfo.cpp:9536
8 	XUL 	nsHTMLPluginObjElementSH::NewResolve 	dom/base/nsDOMClassInfo.cpp:9908
9 	XUL 	xpc::XrayWrapper<JSCrossCompartmentWrapper>::resolveOwnProperty 	js/src/xpconnect/wrappers/XrayWrapper.cpp:475
10 	XUL 	xpc::XrayWrapper<JSCrossCompartmentWrapper>::getPropertyDescriptor 	js/src/xpconnect/wrappers/XrayWrapper.cpp:544
11 	XUL 	js::JSProxyHandler::get 	js/src/jsproxy.cpp:118
12 	XUL 	xpc::XrayWrapper<JSCrossCompartmentWrapper>::get 	js/src/xpconnect/wrappers/XrayWrapper.cpp:781
13 	XUL 	js::proxy_GetProperty 	js/src/jsproxy.cpp:800
14 	XUL 	InlineGetProp 	js/src/jsobj.h:1223
15 	XUL 	js::mjit::stubs::GetProp 	js/src/methodjit/StubCalls.cpp:1902
Crash Signature: [@ nsPluginInstanceOwner::GetPluginPortFromWidget ]
It is #3 top browser crasher on Mac OS X in 5.0.1 and #5 in 6.0.

More reports at:
Ever confirmed: true shows a spike for this in Firefox 7. In addition it shows up in the Firefox 6 report - 

Some of the comments mention Hulu. 

Could be related to the new version of flash, but I cannot see the version people are running in the Mac reports.
It's #3 top crasher (#1 without crashes specific to Mac OS X 10.7.1 and below) on Mac OS X in 7.0.1 and 6.0.2.

There are two kinds of stack traces:
Frame 	Module 	Signature [Expand] 	Source
0 	XUL 	nsPluginInstanceOwner::GetPluginPortFromWidget 	dom/plugins/base/nsPluginInstanceOwner.cpp:3025
1 	XUL 	nsObjectFrame::CallSetWindow 	layout/generic/nsObjectFrame.cpp:809
2 	XUL 	nsPluginHost::InstantiateEmbeddedPlugin 	dom/plugins/base/nsPluginHost.cpp:1094
3 	XUL 	nsObjectFrame::InstantiatePlugin 	layout/generic/nsObjectFrame.cpp:732
4 	XUL 	nsObjectFrame::Instantiate 	layout/generic/nsObjectFrame.cpp:2198
5 	XUL 	nsObjectLoadingContent::Instantiate 	content/base/src/nsObjectLoadingContent.cpp:1907
6 	XUL 	nsAsyncInstantiateEvent::Run

Frame 	Module 	Signature [Expand] 	Source
0 	XUL 	nsPluginInstanceOwner::GetPluginPortFromWidget 	dom/plugins/base/nsPluginInstanceOwner.cpp:3025
1 	XUL 	nsObjectFrame::CallSetWindow 	layout/generic/nsObjectFrame.cpp:809
2 	XUL 	nsPluginStreamListenerPeer::OnStartRequest 	dom/plugins/base/nsPluginStreamListenerPeer.cpp:664
3 	XUL 	nsObjectLoadingContent::OnStartRequest 	content/base/src/nsObjectLoadingContent.cpp:742
4 	XUL 	nsHttpChannel::CallOnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:717
5 	XUL 	nsHttpChannel::ContinueProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1168
6 	XUL 	nsHttpChannel::ProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1105
7 	XUL 	nsHttpChannel::ProcessResponse 	netwerk/protocol/http/nsHttpChannel.cpp:1055
8 	XUL 	nsHttpChannel::OnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:4015
9 	XUL 	nsInputStreamPump::OnInputStreamReady
Hardware: x86_64 → All
---------------------------------[ Triage Comment ]---------------------------------

This has been around for a while at similar levels. While we really need to fix this, the tracking flag is not used to push on a particular issue unless it is specific to a Firefox version. Because this is not, we are not tracking it.

If a safe fix is found please nominate it for beta/aurora approval.
Assignee: nobody → joshmoz
Group: core-security
I was able to reproduce this bug reliably with the reporter's steps. The problem is that nsObjectFrame makes an NPP_SetWindow call (via nsPluginInstanceOwner::FixUpPluginWindow) during which the plugin runs script. The script removes content and causes the nsObjectFrame that called NPP_SetWindow to be destroyed. We don't check for this destruction and later on we try to access an instance variable of the frame (mInstanceOwner->GetPluginPortFromWidget). The unchecked call to NPP_SetWindow via FixUpPluginWindow only happens on Mac OS X.

Marking this security sensitive. It's probably possible to craft an attack by creating a page with a plugin instance that forces this exploitable crash. May even be possible with Flash.
Whiteboard: sg:high
Attached patch fix v1.0Splinter Review
Attachment #569960 - Flags: review?(roc)
Comment on attachment 569960 [details] [diff] [review]
fix v1.0

Attachment #569960 - Flags: review?(roc) → review+
edmorley merged this to mozilla-central:

Resolving fixed.
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Attachment #570263 - Flags: approval-mozilla-aurora?
Attachment #570263 - Attachment description: aurora fix v1.0 → aurora/beta fix v1.0
Attachment #570263 - Flags: approval-mozilla-beta?
Comment on attachment 570263 [details] [diff] [review]
aurora/beta fix v1.0

[Triage Comment]

Approving for 9aurora. We don't want this for 8beta as it is a sg:high and taking anything at this point is risky.
Attachment #570263 - Flags: approval-mozilla-beta?
Attachment #570263 - Flags: approval-mozilla-beta-
Attachment #570263 - Flags: approval-mozilla-aurora?
Attachment #570263 - Flags: approval-mozilla-aurora+
Adding [qa+] for visibility during bug verification. Crasher with clear steps to reproduce in commenta #0. It whould be easy to verify.
Whiteboard: sg:high → sg:high,[qa+]
I built the plugin as given by the steps in comment 0. Sadly I cannot reproduce the crash with Firefox 4 on OS X 10.7.2. Does it only affect 10.6? Or did I something wrong by compiling the plugin code?
Whiteboard: sg:high,[qa+] → sg:high,[qa?]
Do not see any instances of this crash on 1.9.2
Whiteboard: sg:high,[qa?] → [sg:high][qa+]
Whiteboard: [sg:high][qa+] → [sg:high][qa?]
Henrik, can you check Socorro? Since this landed on Firefox 9 back on Oct 31 we can call this verified assuming there are no recent occurrences of this crash.
Right, crashstats will help us here but I wanted to really verify the fix. But without a working testcase it's not possible. So lets take the crashstats route.

Given by the signature summary no crashes have been reported on OS X for Firefox 9 and later. That means we can assume that this crash has been successfully fixed.
Whiteboard: [sg:high][qa?] → [sg:high][qa!]
Alias: CVE-2011-3664
Group: core-security
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.