1089012 - PlugIn Check for VideoLan correctly reports current version for the NPAPI browser plugin version 2.1.3, but database incorrectly reports it as outdated

Status: RESOLVED WONTFIX

(Plugin Check Graveyard :: General, defect)

Description

[john]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141011015303

Steps to reproduce:

After Fox plugin check notification that VideoLan was outdated, ran the update.

Updated VideoLan from 2.1.3 to 2.1.5



Actual results:

After the update, subsequent plugin check -still- shows 2.1.3 as the plugin, and the current version as 2.1.5


Expected results:

Checking the videoLan website and forum, I discovered that the VideoLan update updated the media viewer program to 2.1.5, but that the NPAPI browser plugin version remains at 2.1.3

It appears that the mozilla core plugin database has been filled with the current media player version, and not the current plugin version.

The forum, there at VideoLan, has some cat fights about the updates' version numbers not matching.

I could not find a reference on whether the bugs/security issues addressed by the 2.1.3 --> 2.1.5 media player update, appear as bugs/security issues within the 2.1.3 plugin version.

Comment 1

[DJ-Leith]

John,

Thanks for your report.
Just so I understand.

In bug 1080606 "Update VLC plugin to 2.1.5" the plugincheck database was updated.
(see bug 1080606 comment #6).


In bug 1038685 comment # 11

DJ-Leith wrote:
> Dan,
> Thanks for confirming that "VLC Web Plugin" has "2.1.0.0" in the 'File Version'
> section of the file metadata, as seen in your screenshot
> https://bug1038685.bugzilla.mozilla.org/attachment.cgi?id=8491651
> Indeed, it is ONLY the 'File Version' field that has "2.1.0.0"
> 
> I think "about:plugins"
> also finds "Version" by using the 'File Version' part of the file metadata.
> 
> I think plugincheck is also reading the same 'File Version' field.

There is more in that comment.

There is more information in that bug, particularly from bug 1038685 comment # 5 onwards,
about VLC using 'one version' for a 'release name', but then NOT putting the SAME
'File Version' into the metadata of the ACTUAL plugin!

I think the 'plugincheck website' CAN read the metadata from the plugin.
It can then compare it with the version as recorded in the 'plugincheck database'.

John, I don't have VLC.

Please can you report:

A.  What does "about:plugins" say for your VLC?

B.  What does plugincheck
https://www.mozilla.org/en-US/plugincheck
say about your VLC?
In particular, what *version* is reported in the "Status" column?
Is the 'reported Status', I mean "Up to Date" or "vulnerable", correct?

C.  What does VLC say about your VLC?

D.  What version of VLC do you think you have?

E.  Can you find the actual plugin file (as reported by "about:plugins")
and can you report the "File Version" as seen in the File Version metadata.

See Dan Pernokis' screenshot (taken on 2014-09-18) as an example. 
https://bug1038685.bugzilla.mozilla.org/attachment.cgi?id=8491651



john ruskin wrote in comment # 0:
> After the update, subsequent plugin check -still- shows 2.1.3 as the plugin,
> and the current version as 2.1.5

I think you are saying: 'I updated my VLC to version 2.1.5 but plugincheck
is reporting the plugin as version "2.1.3" '.

Now, it could be that VLC have NOT altered the metadata in the plugin
(or they have NOT matched the plugin metadata to the 'general version number').


What we need to do is get the 'File Version of the PLUGIN', which is in the metadata,
into the 'plugincheck database' and then use that to assess the plugin.
To ask the question: is this plugin vulnerable?

john ruskin wrote in comment # 0:
> It appears that the mozilla core plugin database has been filled with the
> current media player version, and not the current plugin version.

DJ-Leith

Comment 2

[john]

DJ:  Thanks for responding:

A: About:Plugins reports: VLC Web Plugin
    File: npvlc.dll
    Path: C:\Program Files (x86)\VideoLAN\VLC\npvlc.dll
    Version: 2.1.3.0
    State: Enabled
    VLC media player Web Plugin 2.1.3

B: PlugInCheck reports: 
Outdated Plugins:
Plugin: VLC Web Plugin; VLC media player Web Plugin 2.1.3
Status: vulnerable; 2.1.3.0

C: VLC seems to say (in the forums....) that 2.1.3 is the plugin number and 2.1.5 is the media player, for the most recent assembled release.   I have no idea whether or not either, or both, are vulnerable (or as is prudently stated for our purposes here: whether the 2.1.3 plugin is vulnerable).   The essence of the comments, there, is that the problem is with Fox's database, having picked up the media player version as the plugin version, and not recognizing that the plugin version did not change.

D: On/about 10-24-14, I downloaded the most recent version of VLC ("2.1.5" Racewind), which installs the 2.1.5 media stand-alone and the 2.1.3 plugIn.  That is what I have installed; the properties for the media player [vlc.exe] version reports:
    VLC media player 2.1.5
    Application
    file version: 2.1.5.0
    VLC media player
    Product version: 2,1,5,0  [[commas, probably due to the authors' European influences...]]
    Size: 124 KB
    Date Modified: 7/22/2014 6:29 PM
    
E: Using the path, above, for the about:plugins, and examining the "npvlc.dll" file -- The properties for this file reports:
    VLC media player Web Plugin 2.1.3
    Application Extension
    file version: 2.1.3.0
    Copyright . . . .
    368 KB
    Date Modified: 7/22/2014 6:29PM    [[ note the -same- production date as the media player ]]
    etc.

Comment 3

[john]

Interesting:  The problems identified in Bug 1080606

Vulnerabilities Fixed in 2.1.4

CVE-2014-3441
CVE-2014-1684

Vulnerabilities Fixed in 2.1.5

CVE  2014-0333 
CVE  2014-3466 

=====
CVE-2014-3441 -- can PNG files crafted in WAVs, become part of the plugin display, or is that an effort and function that the player undertakes?  In which case, it may not be a plug in problem for the 2.1.3 player, only [ ??? ].  On another hand, if this vulnerability stems from the conditions identified in 2014-0333, then it is not a problem.

CVE-2014-1684 -- speaks of a problem in the player -before- 2.1.3, which would imply that this is not a problem for the 2.1.3 plugin or the 2.1.3 player

CVE-2014-0333 -- the identified library component with problems, 'libpng 1.6.x through 1.6.9' appears to not be part of the VLC package anymore (https://wiki.videolan.org/Contrib_Status/ identifies current as 1.6.10)  I couldn't say whether or not the 2.1.3 plugin uses (still, or at all) the LibPNG, but I am tempted to assume that any reference in the installer package would now use the 1.6.10 variant.   Of course, I also have no idea whether the plugin even uses PNG... because if the plugin didn't, this vulnerability would not become a problem

CVE-2014-3466 -- similarly, the gnuTLS version now current in VLC (same URL) is 3.2.17, which is not within the vulnerability identified.  I propose the same reasoning.

I can assume that -no- changes were made to the plug in, and that all changes in the libraries underlying VLC were adopted by those library updates.  This might explain why there was no change to the plugin version; the other explanation is the the plugin doesn't do anything with the defective libraries (of this, I have -no- idea).   Why there isn't a new compile version numbering for the pluging, just to make everyone happy, is beyond me.

Perhaps, the recommendation at https://bugzilla.mozilla.org/show_bug.cgi?id=1080606#c2, might be misdirected, arising from the confusion that comes from VideoLan's authors changing VLC library parts, and not changing the plugin and therefore not changing the plugin version number.?

CC'g Chandra Mohan, since he wrote that comment and related comments.
Also: See also 1080606, the bug he had file, and marked 'resolved fixed'
Also: Placed a see-also, there, to this bug

Comment 4

[DJ-Leith]

John,
your evidence in comment # 2 is very helpful - thank you.
I also think that your new summary is excellent.

I am now fairly confident that the best way to fix this is for
Schalk Neethling to alter the 'plugincheck database'.

Schalk,
please modify the record for the VLC plugin to make the "latest"
to be "2.1.3" (NOT 2.1.5).

My understanding, based on John's evidence AND on 'previous odd
use of metadata at VLC' (see examples in bug 1038685) is as follows:-

VLC Media Player, version 2.1.5 - has a plugin (npvlc.dll) with "2.1.3"
in the metadata of the plugin!!

john ruskin wrote in comment # 2:
> D: On/about 10-24-14, I downloaded the most recent version of VLC
> ("2.1.5" Racewind), which installs the 2.1.5 media stand-alone and the
> 2.1.3 plugIn.  That is what I have installed; the properties for the
> media player [vlc.exe] version reports:
>     VLC media player 2.1.5
>     Application
>     file version: 2.1.5.0
>     VLC media player
>     Product version: 2,1,5,0  [[commas, probably due to the authors' European influences...]]
>     Size: 124 KB
>     Date Modified: 7/22/2014 6:29 PM

john ruskin wrote in comment # 2:
> A: About:Plugins reports: VLC Web Plugin
>     File: npvlc.dll
>     Path: C:\Program Files (x86)\VideoLAN\VLC\npvlc.dll
>     Version: 2.1.3.0
>     State: Enabled
>     VLC media player Web Plugin 2.1.3

john ruskin wrote in comment # 2:
> E: Using the path, above, for the about:plugins, and examining
> the "npvlc.dll" file -- The properties for this file reports:
>     VLC media player Web Plugin 2.1.3
>     Application Extension
>     file version: 2.1.3.0
>     Copyright . . . .
>     368 KB
>     Date Modified: 7/22/2014 6:29PM    [[ note the -same- production date
> as the media player ]] etc.


The 'plugincheck database' has "2.1.5" as the latest version of VLC media player
(since bug 1080606 "Update VLC plugin to 2.1.5" - see bug 1080606 comment #6,
the 'plugincheck database' was updated on 2014-10-17)


Users of the 'plugincheck website', who have VLC, like John, see:

john ruskin wrote in comment # 2:
> B: PlugInCheck reports: 
> Outdated Plugins:
> Plugin: VLC Web Plugin; VLC media player Web Plugin 2.1.3
> Status: vulnerable; 2.1.3.0

So,
https://www.mozilla.org/en-US/plugincheck
is corectly 'detecting' the plugin version as "2.1.3.0"
BUT
it is reporting, IN ERROR, that it is "vulnerable".

DJ-Leith

Comment 5

[DJ-Leith]

Another possible duplicate: see bug 1097853
This includes a link to:

"I have downloaded several times but the VLC 2.1.5 VLC web plugin
version 2.1.3 has been , how do I update it?"
https://support.mozilla.org/en-US/questions/1026753

Users are, understandingly, getting worried and confused.
They are getting frustrated too.

DJ-Leith

Comment 6

[john]

Yes, DJ, after reading the Moz support page you referenced, and then bug 1097853, I concur -- It's a duplicate.  Unfortunately, I couldn't log into the Moz support page, otherwise there I would have added a reference to this bug 1089012 for readers there.   If anyone can post that, it might help folks who subsequently look there for assistance.

Comment 7

[Schalk Neethling [:espressive]]

I am just giving a general status update here, and will copy this over to any other relevant bugs where a needinfo request has been logged for me.

For the past quarter i.e. 1024-Q4, plugincheck has not been on my radar in any way, shape or form as I was moved to work on another project and 100% of my time was assigned to it. I have kept my eye on bugs etc. that has come an gone and have had the service in the back of my mind though and, from what I have seen this service is still very important to users and Mozilla for a variety of reasons which I will not go into here.

With all of that said, during this time there was also some out reach done to other groups within in Mozilla to take over part, or all, responsibility for plugincheck but, as of right now, there has been no takers.

AS I mentioned though, I completely understand and appreciate the importance of this service and, I also acknowledge that in it's recent, and current state, it does not provide the 'answers' users need but, I am moving pluginchck back as a top priority for myself in Q1 of 2015 and I am currently in the progress of planning for the year in general and then for Q1 specifically.

I want to open this up to the user base to get your input on what is important and the biggest pain points but, have not decided how I will do this.

Once all of these ducks are in a row, I will post a message to either a specific bug, to yammer or both. Please except my apologies for the steady decline of this service, thanks for your patience and continued feedback and I am certain that plugincheck is going to turn the corner in a positive way in 2015.

Comment 8

[Michael S]

I can confirm this is present as of today using FF v34.0.5 with VLC 2.1.5 on windows.

Plugin check page: http://i.imgur.com/KRfWboC.png

VLC Version: http://i.imgur.com/Dl222BL.png

Actual file properties from npvlc.dll extract from v2.1.5 win32 installer: http://i.imgur.com/DpDVPps.png

Per VideoLAN, there is no update to the web plugin to 2.1.5 and 2.1.3 is latest.

Comment 9

[dewi]

Seems to me that this is a VLC issue, and the plugin should not be removed from plugincheck until they fix their plugin so that it is not exploitable as an attack vector.

They state (https://forum.videolan.org/viewtopic.php?f=2&t=116729) that they should not need to upgrade their plugin version, since the flaw was in the separately-installable player, which was fixed and had its version number updated; and that on some platforms, the plugin and player are entirely separate install packages. They just happen to be in a single package on windows "for convenience".

This means that even if they did increment the plugin version number, users could still upgrade the plugin and not the player, and remain vulnerable.

That means that the VLC player *of any version number* remains a known-insecure attack vector until/unless they release a version that either:
1) explicitly prevents the relevant attacks being passed to any player, or
2) restricts the vulnerable players from being used.

It is the responsibility of each plugin author to ensure that their plugins do not call known-vulnerable dependencies; it is not Mozilla's responsibility to parse each plugin's code to find what version of every single dependency it calls.

Comment 10

[dewi]

Logged a ticket with Videolan as https://trac.videolan.org/vlc/ticket/13228

Comment 11

[john]

Oddly, the recent incarnation of the plugin database now reports VLC as an unknown plugin.

What happened to Thomas' suggestion at comment 4 in Bug 1097853:   Moz plugin check should check the VideoLan plugin version and not (or "not merely") the media player version?

Comment 12

[john]

(In reply to dewi from comment #10)
> Logged a ticket with Videolan as https://trac.videolan.org/vlc/ticket/13228

The reverberation of one comment #2, there, overwhelms the better suggestion at comment #3, there.

But, as an aside, Dewi:  If the VLC plugin for Fox reports as 2.1.3, and that plugin is called by the Fox browser (ie, the underlying media player is NOT called), is there still a vulnerability in that course of action?

Compared to:
Rather than Fox calling on the Plugin to open a file with a media extension from within Fox (using a plugin), I set Fox to open a media URL by calling the separate VLC media program.

Are these two cases different?   With different exposures to the Fox browser users?

Or, 
Does the VLC plugin call the VLC media program (and whatever libraries are used, there), no matter what?
Therefore, if the Fox Browser user has that VLC Plugin, and updated/installed the plugin separately from the media program (therefore with a new plugin)(and therefore possibly with an old media version with an exposed underlying library...), and uses the VLC plugin...
That particular kind of user is exposed...?

Comment 13

[john]

Given the comment 12 inquiry...

I note that we are doing a disservice to the Fox user base, with installed VLC plugins, by reporting the plugin as unknown.  

Instead, we should report it as vulnerable, and explain exactly why it is vulnerable in simple language -- along the lines of "Make sure you update the media player to version 2.1.5.   If you updated the FOX VLC plugin separately with VLC, this update will not happen, and your plugin is insecure."

Most people I know who run this check, manually, don't look at the "unknown" list, at all.   And I don't even know what users see if they set plugins to update automatically (does Moz/Fox/Thunderbird even have an automatic plugin check.....?)

Should this comment be placed as a new bug....?   That is, a suggestion/bug that calls for a means to inform VLC plugin users why their VLC plugin is exposed...?

Comment 14

[dewi]

In the VLC bugtracker comments for this issue, the second comment contains the line "They refuse to let us install plugins as .xpi, and they refuse to call versionInfo() to check the version." 

I think what this means, is that the following code displays the version of the called player as "2.1.5 Rincewind" (the version of the PLAYER), when using the web plugin 2.1.3.0.

<!DOCTYPE html><html><title>VLC Version Check</title><body>
<embed type="application/x-vlc-plugin" id="vlc" style="visibility:hidden" />
<script type="text/javascript"><!--
var vlc = document.getElementById("vlc");
alert("Version: " + vlc.VersionInfo);
//--></script></body></html>

Making a special-case API call to the plugin in this case may be more hassle than it's worth, since it sets a precedent that plugin manufacturers can create their own "check I'm not vulnerable" API functions and expect you to know the syntax for every single one them.

So I still see this as a VLC issue: I feel that they need to release a version of their plugin that ensures it *can't* call known-insecure versions of their player.

But if you're willing to put the work in to specialcase them, then this workaround exists.

Comment 15

[dewi]

Ref for above code: https://wiki.videolan.org/Documentation:WebPlugin/

Comment 16

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/