permanently blocklist VLC plugin




10 years ago
3 years ago


(Reporter: timeless, Assigned: dveditz)


Firefox Tracking Flags

(Not tracked)





10 years ago
the vlc plugin doesn't handle oom.

given that attackers persistently try to exploit us by controlling OOM scenarios and then picking vectors, this makes VLC such a vector.
Where is the difference to bug 470936?

Comment 2

10 years ago
bug 470936 assumes they're a cooperative plugin which is helpful to our customers.

this is different, it acknowledges the reality that they're just an exploit vector.

we should fix one or the other.

personally from a security standpoint, this is the one we should fix. eventually if they change their mind and fix their code, we'd need a blocklist entry for the version until which they hadn't which would be newer than 1.0.

if we want our users to be able to use vlc as a plugin (with risk of exploit), but not to constantly crash (in general, not because of malicious content), then we should fix the other.

Comment 3

10 years ago
I can't disagree with your logic here, but I would suspect that blocking VLC entirely would probably make some users just disable blocklisting.

Any way we could get a second opinion on their wontfix? I wouldn't think they'd want to have their plugin unusable in Firefox, so maybe someone could nicely threaten them into looking into this more.
Duplicate of this bug: 470936
We should contact the vendor.
Assignee: nobody → nnguyen

Comment 6

10 years ago
morgamic: the vendor was contacted before these bugs were filed. A contributor has commented in the other bug, and is on the cc list here.

dave: the second opinion can come after we blocklist. we could e.g. relax it when they change their mind.
Dan, can you weigh in here on the security implications and whether or not we should blocklist this?
Assignee: nnguyen → dveditz

Comment 8

10 years ago
Well, we (VLC team) come quite friendly to see you and advise you to block some old versions that can crash easily when multiple instances are used.

Your answer is to close the old bug and to request to blacklist completely VLC, because of issue that could happen with unchecked realloc in the code (OOM situations that are very difficult to manage in videos decoding). 

What do you want us to say?
Hey jb - I don't think that was the intention, sorry if you got the wrong impression.  We all want to do what's best for the users; the other bug looks better to me, we should reopen that one.
See bug 470936.
Last Resolved: 10 years ago
Resolution: --- → WONTFIX

Comment 11

10 years ago
so, jb, you haven't reopened the bug in your bug tracker. until you do, we've given you warning, and you haven't acted. you were also cc'd on this bug when i filed it. i was not hiding anything.

personally, if you are of the opinion that you'll actually fix your oom bug, then i <want and> expect you to *reopen* it in your tracker and *acknowledge* that you're willing to work on fixing such bugs. i will gladly work with you to help you identify such locations so that you can fix them.

however, at this time, all of your plugins are rogue, and you've been on notice for five months.

that said, as long as we block at least some of your plugins and you eventually improve them so we can encourage users to upgrade to better plugins, i'll be happy. I'm not the owner of blocklisting and am not involved in treating these bugs as binary.

[editorial note: the http url redirects to the https site with the cacert, so i'm changing the url field back to https]
Dan - up to you what you want to do here.

Comment 13

10 years ago
1) Bug has been reopened.

2) We are a small team (working on our free time), and I hope we can fix it fast, but I don't know the timeline yet.

3) "all of your plugins are rogue", I hope you have checked all plugins source code that work on Mozilla, and that we are the only ones having issues...

4) I think in OOM situation, the realloc issue is not the only one, but I'll check that later with fenrir

Comment 14

10 years ago
first, thank you very much for reopening the bug in your bug tracker. Verifying this bug as wontfix.

i've looked at a number, and i've watched response times for quite a few, in general other plugins respond properly to problems which involve crashes like this.

the only exception that comes to mind is merely a DoS (java likes to call exit() when it gets upset), but it's not exploitable, just terribly annoying, and at some point I may push sun more forcefully.

note that not checking malloc() is risky and can be dangerous in stream operations, however not checking realloc() is a bigger problem because of how realloc works and how it's used (again in stream operations).

the lesson from all of this is look before leaping.

Try to Allocate. Look at result. Use allocation. Skipping the second step led to this series of bugs.

I looked and found a problem for us, I reported it [here]. I looked and found a problem for you, I reported it [to you]. I got a message [in your system], I reported it [here].

I'm not asking for any specific timeline, just sequencing. As long as you commit to working to fix the problem you get a lot more leeway than if you leave the visible stance as "wontfix".
Thanks guys for working this out!
Product: → Toolkit
You need to log in before you can comment on or make changes to this bug.