Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About the “Security Issue” on VLC

twitter.com

Post reply on HN
Print view View original

51–60 of 174 posts

Re: About the “Security Issue” on VLC

#51

Post by pbhjpbhj »

jbk wrote: post #34
pbhjpbhj wrote: post #31

Earlier quoted context omitted.

[Edit, see below.]

VLC is open source, distributed by VideoLAN non-profit and is totally non-commercial. The only money received by the non-profit is through donations.

I didn't express that well: In copyright terms, if you compete with commercial; or acquire money via a side-channel then it's "commercial" ... what I was trying to express was that it occupies a space where it's serious software and that damage to it's reputation should be treated just as seriously as damage to a sold product from a for-profit.

Apologies.

Re: About the “Security Issue” on VLC

#52

Post by remedan »

M2Ys4U wrote: post #25
codewithcheese wrote: post #18

> The reporter is using Ubuntu 18.04, which is an old version of Ubuntu, and clearly has not all the updated libraries. It's not a "old" version of Ubuntu its the latest LTS.

LTS == old. That's the point of LTS.

The point of LTS is that it's old but still receiving security fixes.

Re: About the “Security Issue” on VLC

#53

Post by middleload »

glandium wrote: post #40

Except if I missed something in my quick research, there doesn't seem to have been a CVE for libebml when it was fixed 16 months ago. So it's really not surprising that LTS distros don't have the fix...

LTS depends on CVEs. And we see here that the CVE database is not entirely trust worthy. The chain is a bit broken.

Re: About the “Security Issue” on VLC

#54

Post by tatersolid »

kalleboo wrote: post #38
onli wrote: post #20

I don't like the exchange with TheRegister: > TheRegister: FWIW we reported the VLC developers were skeptical. Happy to update our coverage accordingly. > Tho, FWIW, the PoC .MP4 seg-faulted our 3.0.7 VLC installation. > VideoLAN: using a linux distribution? with an old libebml? > TheRegister: Using Debian 9.9, using libebml4v5 1.3.4-1 > VideoLAN: Yes, so your issue is your distribution is not up-to-date, not VLC. No…

Is it now the responsibility of every piece of software to check the versions of every library they're linked to for security patches? Shouldn't that be the responsibility of the distribution? edit: is there even a common method for the developer of a library like libebml to flag an update as a security fix to increase the priority of it, or is that up to the package maintainers of each individual distribution to det…

> Is it now the responsibility of every piece of software to check the versions of every library they're linked to for security patches?

Yes, managing dependencies is absolutely the developers’ responsibility. Choosing only well-maintained dependencies is part of that management.

> Shouldn't that be the responsibility of the distribution?

Not completely. You decided to take that dependency to save yourself effort. The distribution did not make that choice. The distribution may not even have a maintainer anymore. You as the developer need to do what you can ensure the “right” version of your dependency is used. This means talking to packagers and distros, and even (gasp) submitting package updates yourself if you rely on a dependency.

Or just bundle local versions of dependencies yourself and stop relying on shared libraries.

Re: About the “Security Issue” on VLC

#55

Post by Zenst »

jbk wrote: post #34
pbhjpbhj wrote: post #31

Earlier quoted context omitted.

[Edit, see below.]

VLC is open source, distributed by VideoLAN non-profit and is totally non-commercial. The only money received by the non-profit is through donations.

Yes, hence they don't have a lawyer ontap, which was kinda the point I was making. The education (what I'm going to call it) that they could bestow upon these bismershing media outlets, would fund much Open Source work for VLC.

Re: About the “Security Issue” on VLC

#56

Post by viraptor »

jbk wrote: post #13
paddlepop wrote: post #8

MITREs response to this is a perfect example of the old-school security team mindset. If I had a nickel for every security team I've worked with that a) treat reporting as gospel and don't validate it, and b) don't talk to the developer. From my experience the key issue is they don't understand the issue enough to engage in a meaningful discussion with the developer

But the biggest issue is that they refuse that we become the CNA for VLC bugs. So, they are the root CNA for VLC bugs, and they don't triage them correctly. And don't update the issues when we mention them.

Not allowing CNA seems to be the biggest issue. Long time ago we had issues where getting a new cve for an open source project was really rare and hard to achieve. Now anyone who asks gets one without validation. Two extremes, likely due to lack of resources, but they won't share the load...

Re: About the “Security Issue” on VLC

#57

Post by dsfyu404ed »

jbk wrote: post #11
Maxious wrote: post #3

Earlier quoted context omitted.

https://news.softpedia.com/news/critical-flaw-in-vlc-media-p... sources https://winfuture.de/news,110171.html sources https://www.cert-bund.de/advisoryshort/CB-K19-0634 sources https://nvd.nist.gov/vuln/detail/CVE-2019-13615 which finally gets to the bug report https://trac.videolan.org/vlc/ticket/22474 To boot https://www.securityfocus.com/bid/109304 claims all versions are vulnerable and the vendor reported it

> To boot https://www.securityfocus.com/bid/109304 claims all versions are vulnerable and the vendor reported it Of course, we never reported such a thing: a security issue in a 3rd party library, fixed more than 16months ago. And VLC binaries were updated 16months ago too... The issue is that MITRE is not doing its job when assigning the CVE or even checking the validity of the claim. But they refuse to talk to us.…

>But they refuse to talk to us. Why?

Because stonewalling is SOP for government bureaucracies when they screw up.

When you're the government the various systems the people you screwed have for recourse work slightly differently so stonewalling works better than spewing out a ton of deny and distract PR like corporations do.

Re: About the “Security Issue” on VLC

#58

Post by tgragnato »

pgeorgi wrote: post #28
jbk wrote: post #26

Earlier quoted context omitted.

Absolutely not: - the reporter never contacted us, we have a clear process and a bounty program. We checked again, he never did. - we receive and process all security issues privately: we fixed 31 of them in the last update. And miracly, the other reporters managed to contact us. - Linux is the smallest OS for VLC. - An issue on one or two Linux distribution for a OOB-read crash is very very different from "VLC vulne…

Since this is tarnishing your brand, maybe ask Ubuntu to cease shipping "VLC" if they do such a half-assed job (enough effort to replace integrated libraries with system packages, not enough effort to maintain those packages)?

> maybe ask Ubuntu to cease shipping "VLC"

I want applications to be packaged by my distribution. Updates are up to maintainers (dependencies included), as it has always been.

If MITRE wants to assign a CVE, warning people that they need an updated lib, that's fine. The issue is the trustworthy and handling of CVEs (... plus reporters).

Re: About the “Security Issue” on VLC

#59

Post by kuschku »

tatersolid wrote: post #54
kalleboo wrote: post #38

Earlier quoted context omitted.

Is it now the responsibility of every piece of software to check the versions of every library they're linked to for security patches? Shouldn't that be the responsibility of the distribution? edit: is there even a common method for the developer of a library like libebml to flag an update as a security fix to increase the priority of it, or is that up to the package maintainers of each individual distribution to det…

> Is it now the responsibility of every piece of software to check the versions of every library they're linked to for security patches? Yes, managing dependencies is absolutely the developers’ responsibility. Choosing only well-maintained dependencies is part of that management. > Shouldn't that be the responsibility of the distribution? Not completely. You decided to take that dependency to save yourself effort. Th…

> Or just bundle local versions of dependencies yourself and stop relying on shared libraries.

That’s what VLC did, Ubuntu/Debian patched VLC to instead use their, older, shared libraries.

I’m not sure what course of action you suggest for developers in such a situation

Post reply on HN