535651 - Plugins can use NPRuntime during painting

Status: RESOLVED DUPLICATE of bug 552512

(Core Graveyard :: Plug-ins, defect)

Description

[Carsten Book [:Tomcat]]

Reproduced with debug build  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b6pre) Gecko/20091217 Namoroka/3.6b6pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7pre) Gecko/20091217 Shiretoko/3.5.7pre (also debug)

Steps to reproduce:
-> Load http://n.yam.com/view/mkvideopage.php/20091202455780
--> Crashes after a few seconds on load - the local copy attached to bug 535641 also do not crash on local tests :/ 

Note, this Bug seems to be related to Bug 535641, when loading this site i either crashed with this stack or with the bug from 535641, there seems some timing issues that cause one of the crashes

(37c.e98): Access violation - code c0000005 (!!! second chance !!!)
eax=ddddde0d ebx=00000000 ecx=ddddde0d edx=00000001 esi=0012e6cc edi=0012e8c4
eip=01a4d31a esp=0012e608 ebp=0012e60c iopl=0         nv up ei ng nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000282

Exploitability Classification: UNKNOWN
Recommended Bug Title: Data from Faulting Address may be used as a return value
starting at gklayout!nsCOMPtr<nsIPluginInstance>::get+0x000000000000000a (Hash=0
x12586f36.0x591b7f23)

The data from the faulting address may later be used as a return value from this
 function.
ChildEBP RetAddr
0012e60c 01b3564f gklayout!nsCOMPtr<nsIPluginInstance>::get+0xa
0012e618 01b34974 gklayout!nsCOMPtr<nsIPluginInstance>::operator nsIPluginInstan
ce *+0xf
0012e638 01b2ddb2 gklayout!nsPluginInstanceOwner::Paint+0x14
0012e8cc 01b2ce3b gklayout!nsObjectFrame::PaintPlugin+0x392
0012e8f8 01a8c71a gklayout!nsDisplayPlugin::Paint+0x3b
0012e910 01a8e17a gklayout!nsDisplayList::Paint+0x6a
0012e924 01a8ec4c gklayout!nsDisplayWrapList::Paint+0x1a
0012e938 01a8c71a gklayout!nsDisplayClip::Paint+0x3c
0012e950 01a8e17a gklayout!nsDisplayList::Paint+0x6a
0012e964 01a8ec4c gklayout!nsDisplayWrapList::Paint+0x1a
0012e978 01a8c71a gklayout!nsDisplayClip::Paint+0x3c
0012e990 01a8e17a gklayout!nsDisplayList::Paint+0x6a
0012e9a4 01a8ec4c gklayout!nsDisplayWrapList::Paint+0x1a
0012e9b8 01a8c71a gklayout!nsDisplayClip::Paint+0x3c
0012e9d0 01aa42db gklayout!nsDisplayList::Paint+0x6a
0012ece4 01a3e413 gklayout!nsLayoutUtils::PaintFrame+0x45b
0012ed18 01e86133 gklayout!PresShell::Paint+0xb3
0012ed78 01e85e16 gklayout!nsViewManager::RenderViews+0xd3
0012ee1c 01e875d4 gklayout!nsViewManager::Refresh+0x2b6
0012ef54 01e8c290 gklayout!nsViewManager::DispatchEvent+0x454
quit:

Comment 1

[Daniel Veditz [:dveditz]]

guessing sg:critical because of the apparently-deleted objects in registers, but it would help to include a bit of the ASM !exploitable usually (always?) spits out to confirm those are relevant in the crash (but it's EAX so I'm assuming it very much is).

Is this just another place we can crash because of the missing rooter in bug 535641? Would be worth retesting after that fix lands.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Bug 535641 isn't blocking due to low volume, and neither is this, though they're both good candidates for an early point release.

That said, this crash looks pretty bad, so maybe I should reconsider blocking on bug 535641? Ugh.

Comment 3

[Johnny Stenback (:jst)]

This looks like Windows media player going out to the event loop when we're telling it to paint, similar to what Silverlight does in some cases, which in this case triggers destruction of the plugin frame which leads to a crash when we're unwinding.

Comment 4

[Johnny Stenback (:jst)]

Jim, could you look into this? Sounds like we need to either do the painting asynchronously, or we need to prevent us from processing plugin messages in our event loop while we're painting. The latter would probably have a smaller impact on performance, but might change how some plugins work in some edge cases.

Comment 5

[chris hofmann]

I'm not able to reproduce when loading http://n.yam.com/view/mkvideopage.php/20091202455780 on a winxp vm  

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

Comment 6

[chris hofmann]

and Windows Media Player Plug-in Dynamic Link Library
    File: npdsplay.dll    Version: 3.0.2.629

Comment 7

[Johnny Stenback (:jst)]

I bet this assertion fires due to the same problem that's described in bug 535651.

Comment 8

[Johnny Stenback (:jst)]

Er, that comment was meant for bug 449129.

Comment 9

[Jim Mathies [:jimm]]

(In reply to comment #4)
> Jim, could you look into this? Sounds like we need to either do the painting
> asynchronously, or we need to prevent us from processing plugin messages in our
> event loop while we're painting. The latter would probably have a smaller
> impact on performance, but might change how some plugins work in some edge
> cases.

There are some unknowns here. The crash stack indicates a crash in PaintPlugin, but AFAICT the windows media plugin in windowed, so PaintPlugin isn't involved in rendering the video. 

Also note there are two version of the video plugin, npdsplay.dll, which was distributed to os <= XP, and np-mswmp.dll whilch you'll find on os >= Vista. You can download the older version here for Vista and up - 

http://kb.mozillazine.org/Windows_Media_Player

The html in the page tries to set this player to windowless through the wmode setting, but both players default to windowed. I'm not sure what's crashing here, I can't tell if it's the video or a windowless flash app in the page. FWIW, I can't reproduce on XP or Win7.

Carsten, are you still able to reproduce this?

Comment 10

[Carsten Book [:Tomcat]]

checking if its reproducible anymore! will report back !

Comment 11

[Carsten Book [:Tomcat]]

so i used media player 11 on XP and Windows Media Player Plug-in Dynamic Link Library

    File: npdsplay.dll
    Version: 3.0.2.629
    Npdsplay dll

Its not crashing anymore but i got assertions when i tried the initial url.
Filed Bug 559429, Bug 559425 and Bug 559432 for this

Comment 12

[Damon Sicore (:damons)]

OK.  So what is next here?

Comment 13

[Benjamin Smedberg]

I'm going to morph this bug to the specific problem that plugins can use npruntime during painting calls in ways which will cause script to run at unsafe times.