1132663 - Block rndlnpshimswf.dll and rndlmainbrowserrecordplugin.dll

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Benjamin Smedberg]

Looking through the crash stats while protected mode was turned off on beta, I discovered a crash signature which was close to 20% of Flash crashes, mozilla::plugins::child::_getproperty

These crashes appear to all be caused by the realnetworks video downloader which is hooking into Flash somehow. See e.g. https://crash-stats.mozilla.com/report/index/c18008fa-7720-41b0-b1ed-379f52150202

I think we should straight-up block this DLL, since it's destined to always be a stability problem.

Chad, can you confirm my decision here?

dmajor, please verify that our DLL blocklist works in the plugin-container process and prepare the necessary patch for blocking these two DLLs.

Comment 1

[Chad Weiner [:chadw]]

Confirmed

Comment 2

[(Away)]

This could break a real use case that some people may want. Has there been any outreach to RealNetworks for a fix from their side?

These crashes are in the latest version (17.0.15.4 from October 2014). Do you want to block all versions or just the latest? Either way has a potential downside.

From the technical side, plugin-container.exe does not currently use the blocklist. I tried hooking up a delayload mozglue but it messed up the fragile DLL balance of bug 1023941. I haven't yet figured out why.

Comment 3

[Benjamin Smedberg]

I don't care about the RealNetworks code working. Hitching a ride on the Flash plugin is not a good way to accomplish that use-case and there are Firefox extensions that solve the same problems without the hooking. Plus youtube is switching away from Flash in the near future anyway.

Comment 4

[(Away)]

So, plugin-container.exe contains a nontrivial amount of code and inevitably a bunch of it calls the malloc family. Linking to mozglue would violate the constraint at https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/WindowsCrtPatch.h#31-32.

Without a pressing need to install the blocklist super early, I'm not inclined to spend time dealing with the library relationships. I propose that we let xul.dll do the initialize call from XRE_InitChildProcess.

Comment 5

[(Away)]

Attachment: Part 1: Use the DLL blocklist in plugin-container processes

I tested that our asserts are still happy on XPSP2.

Comment 6

[(Away)]

Attachment: Part 2 - Block rndlnpshimswf.dll and rndlmainbrowserrecordplugin.dll

I checked that these DLLs don't get loaded, and that the Real addon gracefully handles the failed loads.

Comment 7

[(Away)]

Attachment: Part 2 - Block rndlnpshimswf.dll and rndlmainbrowserrecordplugin.dll

I checked that these DLLs don't get loaded, and that the Real addon gracefully handles the failed loads.

Comment 8

[Benjamin Smedberg]

Comment on attachment 8565272 [details] [diff] [review]
Part 2 - Block rndlnpshimswf.dll and rndlmainbrowserrecordplugin.dll

I think we should block all versions.

Comment 9

[Benjamin Smedberg]

And just to avoid friction, r+ with ALL_VERSIONS.

Comment 10

[(Away)]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/e873eb61dba8
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/90995b26caef

Comment 11

[(Away)]

Attachment: Part 2 - Block rndlnpshimswf.dll and rndlmainbrowserrecordplugin.dll

as landed, with ALL_VERSIONS

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e873eb61dba8
https://hg.mozilla.org/mozilla-central/rev/90995b26caef

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

We've never release noted blocking DLLs before - is there something special about these two (very long-named) that makes us want to change that?  Should I be noting that the Real addon will be blocked from this version forward (which is also something we don't typically put in release notes).

Comment 14

[(Away)]

The RealDownloader will be blocked. Somebody may be deliberately using it, and may be surprised when it stops working. (Or maybe not, I don't know.) If these things are normally not mentioned, then ok.

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

Ok, good to know.  As addon blocking is not something we release note, I'm removing the flag here.  NI? to Tyler so that UA has awareness that this may come up in feedback.