471443 - permanently blocklist VLC plugin

Status: VERIFIED WONTFIX

(Toolkit :: Blocklist Policy Requests, defect)

Description

[timeless]

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.

Comment 1

[Fred Wenzel [:wenzel]]

Where is the difference to bug 470936?

Comment 2

[timeless]

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

[Dave Garrett]

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.

Comment 5

[Michael Morgan [:morgamic]]

We should contact the vendor.

Comment 6

[timeless]

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.

Comment 7

[Michael Morgan [:morgamic]]

Dan, can you weigh in here on the security implications and whether or not we should blocklist this?

Comment 8

[jb+mozilla]

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?

Comment 9

[Michael Morgan [:morgamic]]

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.

Comment 10

[Michael Morgan [:morgamic]]

See bug 470936.

Comment 11

[timeless]

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]

Comment 12

[Michael Morgan [:morgamic]]

Dan - up to you what you want to do here.

Comment 13

[jb+mozilla]

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

[timeless]

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".

Comment 15

[Michael Morgan [:morgamic]]

Thanks guys for working this out!