Bug 649079 (CVE-2011-3664)

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




6 years ago
5 years ago


(Reporter: Richard Bateman, Assigned: Josh Aas)


({crash, crashreportid})

2.0 Branch
Mac OS X
crash, crashreportid

Firefox Tracking Flags

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


(Whiteboard: [sg:high][qa!], crash signature, URL)


(2 attachments)



6 years ago
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 (http://www.firebreath.org) 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 ./prepmac.sh 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 https://github.com/firebreath/FireBreath/raw/master/examples/FBTestPlugin/test.html
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 https://crash-stats.mozilla.com/report/index/de472a68-35cf-42f7-a1fd-b2a472110411

Crash ID: de472a68-35cf-42f7-a1fd-b2a472110411


6 years ago
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

Comment 1

6 years ago
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 ]

Comment 2

6 years ago
It is #3 top browser crasher on Mac OS X in 5.0.1 and #5 in 6.0.

More reports at:
status-firefox5: --- → affected
status-firefox6: --- → affected
status-firefox7: --- → affected
tracking-firefox6: --- → ?
Ever confirmed: true


6 years ago
tracking-firefox6: ? → -
https://crash-analysis.mozilla.com/rkaiser/2011-10-06/2011-10-06.firefox.7.explosiveness.html shows a spike for this in Firefox 7. In addition it shows up in the Firefox 6 report - https://crash-analysis.mozilla.com/rkaiser/2011-10-06/2011-10-06.firefox.6.explosiveness.html. 

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.

Comment 4

6 years ago
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
tracking-firefox8: --- → ?
Hardware: x86_64 → All

Comment 5

6 years ago
---------------------------------[ 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.
tracking-firefox8: ? → -


6 years ago
Assignee: nobody → joshmoz


6 years ago
Group: core-security

Comment 6

6 years ago
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

Comment 7

6 years ago
Created attachment 569960 [details] [diff] [review]
fix v1.0
Attachment #569960 - Flags: review?(roc)
Comment on attachment 569960 [details] [diff] [review]
fix v1.0

Attachment #569960 - Flags: review?(roc) → review+

Comment 9

6 years ago
pushed to mozilla-inbound

edmorley merged this to mozilla-central: https://hg.mozilla.org/mozilla-central/rev/0e56baae8d1d

Resolving fixed.
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10

Comment 11

6 years ago
Created attachment 570263 [details] [diff] [review]
aurora/beta fix v1.0


6 years ago
Attachment #570263 - Flags: approval-mozilla-aurora?


6 years ago
Attachment #570263 - Attachment description: aurora fix v1.0 → aurora/beta fix v1.0
Attachment #570263 - Flags: approval-mozilla-beta?

Comment 12

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

Comment 13

6 years ago
pushed to aurora (FF9)

status-firefox10: --- → fixed
status-firefox8: --- → affected
status-firefox9: --- → fixed
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
status1.9.2: --- → unaffected
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
You need to log in before you can comment on or make changes to this bug.