649079 - (CVE-2011-3664) firefox crashes when loading npapi plugin OOP and mimetype is set before injection into the dom [@ nsPluginInstanceOwner::GetPluginPortFromWidget ]

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Richard Bateman]

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

Comment 1

[timeless]

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	Mac OS X
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

Comment 2

[Scoobidiver (away)]

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

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsPluginInstanceOwner%3A%3AGetPluginPortFromWidget

Comment 3

[Marcia Knous [:marcia]]

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

[Scoobidiver (away)]

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

Comment 5

[LegNeato]

---------------------------------[ 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.

Comment 6

[Josh Aas]

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.

Comment 7

[Josh Aas]

Attachment: fix v1.0

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 569960 [details] [diff] [review]
fix v1.0

r=me

Comment 9

[Josh Aas]

pushed to mozilla-inbound

http://hg.mozilla.org/integration/mozilla-inbound/rev/0e56baae8d1d

Comment 10

[Bobby Holley (:bholley)]

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

Resolving fixed.

Comment 11

[Josh Aas]

Attachment: aurora/beta fix v1.0

Comment 12

[LegNeato]

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.

Comment 13

[Josh Aas]

pushed to aurora (FF9)

http://hg.mozilla.org/releases/mozilla-aurora/rev/95d475c2449d

Comment 14

[juan becerra [:juanb]]

Adding [qa+] for visibility during bug verification. Crasher with clear steps to reproduce in commenta #0. It whould be easy to verify.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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?

Comment 16

[Daniel Veditz [:dveditz]]

Do not see any instances of this crash on 1.9.2

Comment 17

[u279076]

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.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=nsPluginInstanceOwner%3A%3AGetPluginPortFromWidget&reason_type=contains&date=12%2F08%2F2011%2000%3A03%3A46&range_value=1&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=nsPluginInstanceOwner%3A%3AGetPluginPortFromWidget