1266190 - two blocklist state entries being displayed under browser console for QuickTime

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect, P2)

Description

[Kamil Jozwiak [:kjozwiak]]

Attachment: issue.png

While testing bug # 1264874, I noticed that two log entries are being displayed under the browser console while manually pinging the live blocklist server. There should only be one entry in the browser console indicating that the item is vulnerable and there is no update, hence the "0 to 5" entry [1]. I'm not sure why there's a second entry that displays "0 to 0".

Example: (image of the issue attached as well)

* Blocklist state for QuickTime Plug-in 7.7.9 changed from 0 to 5 (correct)
* Blocklist state for QuickTime Plug-in 7.7.9 changed from 0 to 0 (incorrect)

Reproduced via:

* Win 10 x64 using 45.0.2 m-r, buildID: 20160407164938 changeset: e35da3da61cb
* Win 8.1 x64 using 48.0a1 m-c, buildID: 20160420030213 changeset: f05a1242fb29
* Win Vista x64 using 46.0b9 m-b, buildID: 20160407053945 changeset: b007110e9005

[1] https://mxr.mozilla.org/mozilla-central/source/xpcom/system/nsIBlocklistService.idl#15

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

There are 4 active blocks for the QuickTime plugin on Windows.

1151 blocks all versions (bug 1264874).
410 blocks 7.7.3 and lower (bug 837377).
30 and 27 block 7.1 (bug 430826). These use a name filter instead of a version filter.

I removed the older blocks since they are all redundant. Please give it another try and see if the problem still occurs.

Comment 2

[Kamil Jozwiak [:kjozwiak]]

I'm still seeing the same two error messages logged in the browser console when pinging the live production blocklist server via the following:

*  Components.classes["@mozilla.org/extensions/blocklist;1"].getService(Components.interfaces.nsITimerCallback).notify(null);

Platforms/builds used:

* Win 10 x64 using fx45.0.2 (m-r) buildID: 20160407164938, changeset: e35da3da61cb
* Win 10 x64 using fx48.0a1 (m-c) buildID: 20160421030302, changeset: 4e3ad95d689a
* Win 8.1 x64 using fx47.0a2 (m-a) buildID: 20160421004015, changeset: d9fdbad8f079

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

There's nothing unusual about this block, so maybe there's something in the Add-ons Manager causing the extra logs. I'll also note that there are 4 logs saying "Blocklist state for QuickTime Plug-in 7.7.9 changed from 0 to 0", as indicated by the count to the right of the image.

Comment 4

[Kamil Jozwiak [:kjozwiak]]

Let me know if there's anything else that I can do here. Will running this case in a debug build provide us with anymore information? Is there any other prefs that we can enable to get more logs via the browser console?

Comment 5

[Dave Townsend [:mossop]]

It's possible that you just have two versions of Quicktime installed on your machine, can you attach a copy of pluginreg.dat from your profile so I can take a look?

Comment 6

[Kamil Jozwiak [:kjozwiak]]

Attachment: pluginreg.dat

I installed QuickTime on a clean Win 10 x64 VM machine so I definitely don't have two different version installed. However, to get the web plugin installed, you'll have to manually select it under the QuickTime installer via "Optional QuickTime Features -> QuickTime Web Plug-in". I only see a single entry under about:addons so maybe the blocklist is checking the regular plugin and the web plugin at the same time?

about:plugin information:

File: npqtplugin.dll,npqtplugin2.dll,npqtplugin3.dll,npqtplugin4.dll,npqtplugin5.dll
Path: C:\Program Files (x86)\QuickTime\Plugins\npqtplugin.dll,C:\Program Files (x86)\QuickTime\Plugins\npqtplugin2.dll,C:\Program Files (x86)\QuickTime\Plugins\npqtplugin3.dll,C:\Program Files (x86)\QuickTime\Plugins\npqtplugin4.dll,C:\Program Files (x86)\QuickTime\Plugins\npqtplugin5.dll
Version: 7.7.9.0
State: Enabled (STATE_VULNERABLE_NO_UPDATE)
The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.

Comment 7

[Dave Townsend [:mossop]]

Ok so Quicktime installs 5 different plugin dlls and we're only blocking one of them currently. I forget what state that ends us up in but it is probably best to include the other dlls in the block.

Comment 8

[Jorge Villalobos [:jorgev] (he/him)]

Is it a single plugin entry, though? The filename is only used to identify the plugin entry to block, and it sounds like all those files are listed in the same entry, so they would all be blocked.

Comment 9

[Dave Townsend [:mossop]]

(In reply to Jorge Villalobos [:jorgev] from comment #8)
> Is it a single plugin entry, though? The filename is only used to identify
> the plugin entry to block, and it sounds like all those files are listed in
> the same entry, so they would all be blocked.

It isn't a single entry to the actual code responsible for loading plugins. The Add-ons manager attempts to merge similar plugins into one in the UI so users aren't confused by them but it looks like the blocklist service processes the full list. What I can't figure out off the top of my head is whether there is some code somewhere that makes sure that the full merged list get blocked if just one of them get blocked. At least I don't see it where I would expect to see it.

Comment 10

[Kamil Jozwiak [:kjozwiak]]

Attachment: plugin.png

(In reply to Jorge Villalobos [:jorgev] from comment #8)
> Is it a single plugin entry, though? The filename is only used to identify
> the plugin entry to block, and it sounds like all those files are listed in
> the same entry, so they would all be blocked.

There's only a single entry that appears under about:addons, as Dave mentioned, the code might handle it differently:
* QuickTime Plug-in 7.7.9
* Points to the following --> https://blocklist.addons.mozilla.org/en-US/firefox/blocked/p1151

See the image attached (plugin.png) for the about:plugin page.

Comment 11

[Andy McKay]

Just to check, is there any bad implication of a result of this? Is security impacted in any way?

Comment 12

[Dave Townsend [:mossop]]

(In reply to Andy McKay [:andym] from comment #11)
> Just to check, is there any bad implication of a result of this? Is security
> impacted in any way?

It's possible that quicktime may still be usable in certain cases despite being blocklisted, it would probably depend on the mimetype. This needs investigating.

Comment 13

[:shell escalante]

andy's comment 11 do you know if this is just an error in the log or is this potentially getting us into a bad state.  The first is a P4 (that likely won't make the cut to fix) versus a P2.5 (that we'd investigate sooner if blocklist is handling/being configured badly)

Comment 14

[Dave Townsend [:mossop]]

See comment 12

Comment 15

[Frankie]

RIP QuickTime for Windows

Comment 16

[Kamil Jozwiak [:kjozwiak]]

(In reply to Frankie from comment #15)
> RIP QuickTime for Windows

Re-opening... Please see comment #12. Even though Apple deprecated quicktime on Windows, some users might still have it installed and we need to ensure that our blocklist is correctly protecting fx users.

Comment 17

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.