Firefox says Plugin "outdated""vulnerable"

[josephrot]

Many sincere thanks to all the respondents, and the detailed discussions ARE appreciated. Having read all of the new responses to this "situation", believe that we all more fully understand the various facets. I think where the concerns and frustrations started was when the involved programming parties appeared to be pointing "it's the other person's fault" at each other, instead of "simply" addressing and "curing" the problem.

Recent communications with Mozilla appear to indicate that many of the Firefox programming staff and testers also use VLC themselves and they finally do have changes to the Firefox PlugIn's Update check on the chart to be "fixed". Thus, the discussions and complaints to both VLC and to Mozilla are being heard and considered. I have not heard of a definitive "will be fixed by" date from Mozilla, but I am advised it is very soon now in nature.

Last but not at all least, I am a "lifelong" champion and supporter of both VLC and Mozilla Firefox, as both represent frankly great ideas and sound products...and I believe that I speak for many others in hoping both continue as such.

Joe

[wensveen]

@josephrot: That's great news. I think the people that are reading and participating in this topic are all supportive of both VLC and Firefox, or we wouldn't have cared at all. So it's good to hear that common ground has been found and a solution can be expected in the future. Is there a bug report or something you can link to?

@RDC: I see your point. I saw your point before, actually, and you make a good case. I don't think Mozilla is purposely trying to defame other Open Source projects. Why would they? They have nothing to gain by that. As I user, I'm very happy that FF warns me when I use a vulnerable java or flash plugin.
A plugin that is effectively an intermediary towards a larger package, like VLC, is problematic. If I wrote a plugin that gave the browser direct access to the command line of the machine it's running on, that would mean that while even though the plugin itself could be bug-free, a lot of vulnerabilities might be exposed by this plugin. One cannot expect the plugin to release an updated version each and every time some arbitrary command or library is updated. BUT, when the plugin is an intermediary towards something controlled mostly by the same vendor, I would expect a new version with each new release (BTW, java does this too). At least to the point you have control over it. So when the library is a shared one, external to the application and updated separately from the application (e.g. apt-get install libavcodec) a new vlc plugin version (browser-plugin-vlc) isn't necessarily warranted. But when the application as a whole is updated and shipped together with updated libraries, then one might expect a new plugin version too. Again, I consider the VLC suite as a whole to have a certain version, but that is just my opinion, which isn't shared by everyone and I respect that choice.

I don't think I've brought anything new to the table, so I'll refrain from repeating myself next time . Good to hear Mozilla is working on it, and thanks for all answers and explanations.

[Rémi Denis-Courmont]

So when the library is a shared one, external to the application and updated separately from the application (e.g. apt-get install libavcodec) a new vlc plugin version (browser-plugin-vlc) isn't necessarily warranted.

Firefox is also complaining on Linux that plugin version 2.1.3 is vulnerable - even though on Debian/Ubuntu (and Linux in general), the web plugin and the player are completley separate packages that are updated separately... So there you go.

Besides, even on Windows you can install the plugin and the player separately. They are bundled in the official executable installer only for obvious user convenience.

[alfs]

@Matthijs:
It's perfectly ok with me to summarise like you do! However, I don't really understand (or agree with) your conclusions...

1. You seem to insist on considering the VLC browser plugin as *A PART OF* the VLC Media Player. It is not. I'm not sure whether your installation (maybe on Windows) is bundling the two, therefore making the plugin seem like it's a library of the player itself, but for me (using Linux and aptitude package manager) it is two completely different pieces of software installed separately. (Obviously, there is a dependency from the plugin to have VLC player itself, but there is no dependency the other way around.) If a vulnerability is found in e.g. one of the codecs used by the VLC player, somebody (release responsible for that codec) is releasing a new version. In that case, any software using this topical codec also needs to pull in the new version (replace the old codec version), re-run their tests, possibly fix sxomething and finally compile their software package with the new codec and release the outcome with a new version number. The browser plugin *IS NOT* such a library -- it is not pulled in and causing a recompile of the VLC media player in a similar manner. Given that interfaces are not changed, the old plugin is still able to make the new version of VLC media player work within the browser frame. I don't have to upgrade the plugin, and all the distributors (e.g RedHat, Ubuntu/Canonical, Apple, ...) won't have to push a new plugin version to their users (similar to Windows update, if you are a Windows user).

2. Now you write this:

The browser, wanting to make sure their users use up-to-date and secure software with up-to-date and secure plugins. So when VLC released version 2.1.5 of the main program, it is in their best interest to alert their users to that fact and suggest they download the new version. The problem is, when asking the plugin for its version it receives the plugin version, 2.1.3. The plug-in itself wasn't insecure or outdated to begin with. That leaves the question of how Firefox is to know when they should alert their users.

Even though I think I understand your intent, I also think there are misundertandingings causing this discussion to go on, and really -- we need to get this straight so people (i.e. we, the users) can start bugging Mozilla rather than peppering VideoLAN's forums/support with these things!

The browser, wanting to make sure their users use up-to-date and secure software with up-to-date and secure plugins.

The browser should not care one single bit about other software I am running on my computer except for the browser itself and its plugins.

So when VLC released version 2.1.5 of the main program, it is in their best interest to alert their users to that fact and suggest they download the new version.

As long as you mean VideoLAN by "their best interest", yes. If you mean Firefox, absolutely not! Why on the earth should Firefox care about which version of VLC (or Libre Office or Adobe Acrobat or whatever) I am running on my computer? I have a system distributor for that (in my case Canonical, providing timely updates to any package I have installed via Ubuntu Software market) *AND* this is the exact reason why VLC media player is checking for new versions at startup just like you point out yourself. I don't want Mozilla to start checking whatever runs on my computer, and I really don't think you do either.
And finally: How do they even know that VideoLAN released the new version 2.1.5 in your case? Certainly VideoLAN didn't tell them anything about any update to the browser plugin (which hasn't taken place), and I have no idea where they picked up the update to the media player. Furthermore, I don't understand why they make any assumption such as this (i.e. browser plugin being updated) without even checking with VideoLAN, who is the one and only authoritative source of version information for the VLC products. The only reason I can see for this is Mozilla's habit of synchronising the versioning of their products, but really -- they are among the few, and they should not expect others to do the same.

So what we want is for Firefox to see is "this is plugin version 2.1.3 using program version 2.1.5, so all is well".

No, I don't want or need Firefox to see this, and I don't understand why anyone else would want to use Firefox as their "version control agent". In my eyes, there is nothing to fix in NPAPI to support such a thing, but Mozilla needs to realise the architecture and the fact that they cannot control the entire computer of their users.

What I truly don't understand, even when VLC would be absolutely right in their position, is that it is in their best interest as well to have Firefox alert their users to the fact that a new version of VLC is released and that they should go and download it. Isn't that what you want too?

Nope again. (Well, I cannot speak for VideoLAN, obviously, but at least for myself as a user...and I would guess it's very likely to go on behalf of VideoLAN as well...) If a new version of the *browser plugin* is released, however, THAT is a different matter, and exactly the difference between those two things is what this entire thread is trying to explain. (Again: If a new version of the VLC player is released, the player would tell you upon startup, independent of Mozilla/Firefox and/or whether the plugin is used, and in my case, the new version would also get pushed by my system update feature, managed by the distributor.)

Currently, there is a lot of doubt about how secure VLC is, because Firefox says so, and while technically incorrect, it does affect user opinion.

Yes, and this is the reason I'm getting upset, writing a lot more than I should and also reporting this to Mozilla, as in my eyes it's plainly a bug on their side! Rather than arguing in this thread, we should all push on Mozilla to fix the problem asap, as both the VLC browser plugin and Firefox are very popular and widespread software packages used by a less tech savvy audience, who shouldn't be falsely scared like this!

Lastly, I do want to point out the difference between a software suite, with all software having the same version, and all of the software of the same vendor.

Sure, my comparison was maybe far fetched (or plainly stupid), sorry, *BUT* you are now considering the "branding version" from Microsoft, and your assumption about "a software suite, with all software having the same version" is false. On my virtual Windows machine, I am running MS Office 2010. However, we all know that there are numerous "service packs" and fixes (many of them also security/vulneraility improvements) pushed through Windows update all the time, exactly like what is happening to the VLC media player. if you look at the real version numbers for the products inside the MS Office package, here's what I currently have:

• Outlook v14.0.7128.5000
• Excel v14.0.7140.5002

These are not the same. (Also, your example comparing Office 2016 to 2013 would be more equivalent to VLC player v1 to v2 (or v2 to future v3) -- this means Microsoft is shrinkwrapping a new top level version of the suite, which holds completely new versions of the products...at least a makeover, but commonly also feature additions. I think the difference between the version numbers I've included above for Outlook and Excel compares better to the 3rd level update from 2.1.3 to 2.1.5 discussed here; The diff between Outlook and Excel are at the 3rd level just like 2.1.3 vs. 2.1.5, the 3rd level updates are handled fairly similarly (Windows update vs. VLC update) and probably the updates are holding approximately the same amount/level of changes, I would guess.)

PS. What do you do when the plugin has a bug which is fixed? Does the VLC program (and suite) version remain the same? (download VLC version 2.1.5 now! again! because it's changed! really!)

Well, it's kind of funny that you end by asking this question, really, since this is exactly when Firefox *should* tell you that your plugin is outdated and that you should upgrade...
As mentioned earlier: There is no need to relase the VLC media player again to fix something in the browser plugin (given that APIs are kept unchanged etc.). On my part, I will have the new version of the plugin pushed by my package system, and this is the exact moment that Mozilla should start caring. If this would happen, I assume that VideoLAN would inform Mozilla asap when a new version of their browser plugin is available.
On the contrary, when the player itself gets upgraded, and VideoLAN is *NOT* releasing anything to the Firefox plugin market, why does Mozilla start assuming something??!
(If, in your Windows installation binary package aka the VLC-intall.exe, the plugin is bundled, it would simply ask to be upgraded after installation, I guess. This is more or less like Windows asks to have all service packs and fixes downloaded and installed if you reinstall your computer from a DVD or from a rescue partition. In my case, the browser plugin is not bundled with the player, and I have to admit I haven't bothered checking other versions for other platforms.)

You end off saying

[...] then VLC and Firefox should cooperate towards a solution.

I think we all agree, and the single thing VLC can really do is to report to Mozilla that Firefox' is currently creating a mess for both VideoLAN (whose poor people have to read all of this and answer the same questions over and over 52365 times) and for all the users.
What WE (the users) should do is moving to Mozilla's support forums and report the problem there. That's the only way to get the problem fixed, really, and it's also the correct audience for our expessions of unhappiness. (FYI: I also have problems with Adobe Flash plugin -- the effect is the same, i.e. Firefox constantly whining about a vulnerable version even though I have the very latest release, but in this case it's technically a slightly different reason.)

So everyone: Go file the problem with Mozilla!

Cheers

[DewiMorgan]

As a programmer, here's the way it looks to me.

Say I write a plugin that allows people to use SSH in the browser. Say in version 1.0.0 of my plugin, I allow all versions of SSL, and maybe a zillion other protocols, or maybe not (you can imagine this scenario both ways: the end answer doesn't seem affected, to me).

Some versions of SSL contain known vulnerabilities, which can be exploited over the web, through my plugin.

The Mozilla programmers ask me how, using only the interface I have provided them, they can tell if the version of SSL that my plugin is currently configured to use will be dangerous for their users to run.

Here are some responses I can give:
1) You cannot. Screw you, and screw your users.
2) You can roll your own thing to grope into my keys in the registry, find which chat clients are configured, and find which SSL clients I have installed, then go and grope into *their* registry keys or whatever to find where *they* are installed, and then check the version of those SSL clients using whatever custom method each one requires, because I'm a special snowflake and you should spend lots and lots of programmer time just on my one plugin. I tell all my users they should file a bug with you, to make you do this. It is not, I assert, my responsibility to check whether it's safe for my program to pass some invalid arguments to some insecure version of the SSL client.
3) I'll make a new API (which you must write extra code to handle, because I am a special snowflake) that lets you query the installed version of every single one of my dependencies.
4) I'll release a version 1.0.1 which prevents (or at least warns) users from running it with known-flawed SSL versions, and recommends or requires they upgrade. The browser manufacturers can just check my version number. I acknowledge in this way that it is my responsibility to check that the applications called through me cannot be exploited.

As a programmer, only option 4 seems legitimate.
Option 3 would work, but raises privacy concerns and is also pointlessly more work on both sides.
Option 2 is an obvious and shameful attempt to avoid work and shift blame that would bring shame to anyone saying it.
Option 1 is, I'm betting, probably the most common response Mozilla gets. At least it's not as intellectually dishonest as option 2.

If I know that there is a version of SSL which can be exploited through my plugin, and I don't release a version of my plugin that checks against this, then my plugin is an attack vector, and is justly marked as insecure by Mozilla.

So, seems to me, whether or not they are released in a single package, whether or not they are written by the same people, the authors of the VLC plugin should make a version which checks that it is not being used with a known-vulnerable version of the VLC app. Otherwise, it is an attack vector, and is justly marked as insecure.

The fact that they are released separately is not an excuse to do nothing and not increment their version number: but it is a reason that even if they released 2.1.5, without a safety check, it should still be marked as a a valid attack vector: people could download and install the new plugin without upgrading their VLC, so there'd be no confidence that the problem was patched.

TL;DR: VLC plugin 2.1.3 is a known attack vector and should remain marked as insecure, unless and until they release a version that prevents use with known-insecure VLC players.

[DewiMorgan]

So everyone: Go file the problem with Mozilla!

VLC ticket: https://trac.videolan.org/vlc/ticket/13228

Mozilla tickets: https://bugzilla.mozilla.org/show_bug.cgi?id=1089012 and https://bugzilla.mozilla.org/show_bug.cgi?id=1097853

[Rémi Denis-Courmont]

The fact that they are released separately is not an excuse to do nothing and not increment their version number:

Indeed, it is not an excuse: Rather it is a good reason to do nothing and not increment the version number.

If there was a security issue in VLC 2.1.4, distributions will pick up VLC 2.1.5. They wouldn't pick up a would-be browser plugin version 2.1.5 that is exactly identical to version 2.1.4 other than the version number. And the end result is that Firefox would still fail, at least if/when it gets updated due to whatever reasons (for instance a separate security issue in Firefox itslef).

[wensveen]

@DewiMorgan: You *are* a special snowflake, everyone is

@RDC:

And the end result is that Firefox would still fail, at least if/when it gets updated due to whatever reasons (for instance a separate security issue in Firefox itslef).

Could you elaborate on this? I don't understand what you mean by failing.

@alfs:
So, let me start with this

*BUT* you are now considering the "branding version" from Microsoft, and your assumption about "a software suite, with all software having the same version" is false.

You got me there. Tried to beat you at your own game, but you were up for it. Shall we call it a draw ?

I run both Windows 7 and Linux (Debian sid/unstable). I looked at it from both viewpoints. The problem is somewhat smaller on Linux (most distro's, probably) because users are used to getting the latest versions through their package managers. I'd trust that over something Firefox/Iceweasel told me (although I'd be sure to update just to make sure). At the moment, in sid, the versions are equal, but I don't know if that's the case everywhere, and whether or not the package maintainers user their own versioning.
In short, I don't think Linux should be something to worry about right now.

Windows, however is a completely different story. I can't imagine any user on Windows downloading the VLC plugin and VLC program separately. Or updating for that matter. How would you even know when to update the plugin? (The plugin doesn't do version checks, does it?) So what one does, as a Windows user (including me with my Windows hat on), is to go to videolan.org and download the latest VLC version. The whole of it. Which has, ostensibly, one version number.

The browser should not care one single bit about other software I am running on my computer except for the browser itself and its plugins.

and

Why on the earth should Firefox care about which version of VLC (or Libre Office or Adobe Acrobat or whatever) I am running on my computer? I have a system distributor for that (in my case Canonical, providing timely updates to any package I have installed via Ubuntu Software market) *AND* this is the exact reason why VLC media player is checking for new versions at startup just like you point out yourself. I don't want Mozilla to start checking whatever runs on my computer, and I really don't think you do either.

Not everything, no. Just the things that may be involved in running content from the websites I'm visiting, that may or may not be trustworthy. But this is just my opinion. You could argue that you have the same problem when you just download the same movie clip from the website, rather than running it via the plugin, but people are less aware of the content being from an untrustworthy source when it's inside the browser. It's just content, like everything else.
I'm not sure the player does a version check when running content via the plugin? That would help, in any case.

I asked: "What do you do when the plugin has a bug which is fixed? Does the VLC program (and suite) version remain the same?" And from my point of view your answer was unsatisfying. On Linux, I agree, the updated plugin is pushed through via the package manager and everybody's happy. On Windows though, the only way the users are going to get a new plugin version, is by downloading vlc-install.exe (vlc-2.5.1-win32.exe). When the version check of VLC player detects an outdated version (does it even detect outdated plugin versions? probably not), you get sent to the download page of the suite. Re-downloading the same installer would be pointless, so we'd have to have a new version of the installer containing VLC player (same version, 2.5.1) and the updated plugin (2.1.4?). Do we need to keep a seperate version of the installer? vlc-2.5.1a-win32.exe might work. But it seems convoluted and kind of pointless. OTOH, this scenario is probably less likely to occur.

Consider the following scenario: VLC player version 3.0.0. is installed on a user's computer, alongside some VLC plugin version that is guaranteed to be secure (no updates will ever be made because it's proven to be and stay secure until the end of time). Some bug is found in the player, allowing executables to be executed on the user's computer when they are named virus.exe.avi. An update is made and whenever someone opens the VLC player or clicks a video file in Windows explorer and thereby opening VLC player, they are warned that a new version is available fixing a critical security issue. Fine, desktop users are happy. But meanwhile, shady websites are putting virus.exe.avi on their pages to be played via the VLC plugin. Users aren't warned by Firefox that a new version of the plugin is available, because there isn't, and on top of that VLC doesn't warn them either because VLC's version check isn't executed either. End result: chaos and mayhem (not necessarily in that order).
To me: "Hey, let's give the plugin the same version of the player so that users can be alerted when a new version of the player is available, even though that is technically slightly incorrect", sounds like a simple solution. If you can convince Firefox to only look at the plugin version, and to get them to acknowledge that this is not the same as the player version. And on top of that make sure the player version check is always run even when content is played via the plugin. That would work for me.

Maybe we should just agree to disagree. In the end, VLC remains a great piece of software. So many thanks to the developers.

[myvlc_version]

why no Vlc will create a fake dll with correct info version 2.1.5.0

i did and no more notify from Firefox

[John connor]

This has been bugging me for a long time with Mozilla saying the VLC web plugin is outdated. I looked at the plugin date and it says from July of last year. I guess this is a Mozilla problem? I shall raise cane with them then.

[robvw]

I guess Mozilla refuses to admit that there version checks are a big failure because they have no other solutions.

What would you the Mozilla devs do? How do you think they should handle version checking on plugins? Saying "it is not my fault, their design is broken" is easy, but it sounds like an excuse, unless you also explain (roughly; no need to actually implement it) what you think is the correct way (which would let them solve the problem, without you making modifications on your end).

In my opinion, this suggestion by DewiMorgan seems very reasonable:

4) I'll release a version 1.0.1 which prevents (or at least warns) users from running it with known-flawed SSL versions, and recommends or requires they upgrade. The browser manufacturers can just check my version number. I acknowledge in this way that it is my responsibility to check that the applications called through me cannot be exploited.

That suggestion doesn't give you any extra work! Inserting those extra checks is a really good idea (or, actually, it's necessary) anyway, especially since you yourself point out how mismatched versions of VLC and the VLC Browser Plugin might get installed. Then when those checks have been inserted, bumping the version number makes a ton of sense; checking for vulnerable dependencies is a new feature.

Of course, until someone actually files a bug with them, this is only guessing. (I don't use their crap anymore so don't count on me to file a bug.)

With all due respect, don't you think it's rather odd to even have a Firefox plugin, if you outright refuse to use that browser? Why include it in the standard installer if there are known issues, which you won't solve? Wouldn't it make a lot more sense to discontinue the Firefox plugin (or, at least, remove it from the default installation) if this is how you feel about it?

Right now you don't want to update the plugin, but what happens when there's a bug in the VLC core which can only be exploited through the plugin? Would you fix such an issue, or would you also say "let Mozilla fix it" in that case...!?


Don't get me wrong, I really like VLC itself, but now that I've finally bothered looking into these weird errors, I'm not really sure what to think of the VLC Browser Plugin.

[Rémi Denis-Courmont]

In my opinion, this suggestion by DewiMorgan seems very reasonable

I don't know and I don't care how reasonable you think it is. It does not make sense: just like Mozilla, it is based on assumptions that are not actually met in reality. This has been explained several times in this very thread already (and at other times in other places).

If you cannot understand or refuse to, then there is no point explaining again.

With all due respect, don't you think it's rather odd to even have a Firefox plugin, if you outright refuse to use that browser?

No. There are several browsers and I use those I like the best.

Why include it in the standard installer if there are known issues, which you won't solve?

Some people evidently want to use it. Why would I remove it? What would I gain from removing it?

I won't solve the problem because I cannot solve it. The problem is in Mozilla code that I have neither permission nor competency to fix.

Wouldn't it make a lot more sense to discontinue the Firefox plugin (or, at least, remove it from the default installation) if this is how you feel about it?

The plugin is not specific to current Firefox versions. It works with any NPAPI-capable browser. Only recent Firefox versions (deliberately) fail to run it.

Right now you don't want to update the plugin, but what happens when there's a bug in the VLC core which can only be exploited through the plugin? Would you fix such an issue, or would you also say "let Mozilla fix it" in that case...!?

If there is a security bug in the plugin and it gets fixed, the plugin will get a new version number. That version might or might not be higher than 2.1.5 (indeed the next available minor version number is 2.1.4).

[robvw]

The plugin is not specific to current Firefox versions. It works with any NPAPI-capable browser. Only recent Firefox versions (deliberately) fail to run it.

They run it just fine... after you override a security warning.

It does not make sense: just like Mozilla, it is based on assumptions that are not actually met in reality.

Then explain how you think it should work. Filing a bug report with Mozilla "your plugin versioning sucks" is not helpful and is guaranteed to be ignored; to have any chance at all to get them to change things, we need an alternative. The approach I consider most reasonable (quoted above) you don't like, fine, but then what? Do you want them to completely forget about blocking vulnerable plugins, do you think they should use a method other than version numbers, do you want them to look at the versions of all code a plugin uses...; in a perfect world, what do you want them to do!?