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

81–90 of 174 posts

Re: About the “Security Issue” on VLC

#81

Post by jakear »

tgragnato wrote: post #58
pgeorgi wrote: post #28

Earlier quoted context omitted.

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

My impression is that VLC did issue an update to use a more recent version of libebml, but Ubuntu/Debian maintainers patched it to use universe’s outdated version (which they don’t even maintain!)

Re: About the “Security Issue” on VLC

#82

Post by rndgermandude »

tatersolid wrote: post #72
kuschku wrote: post #59

Earlier quoted context omitted.

> 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

> I’m not sure what course of action you suggest for developers in such a situation Talk to somebody at Debian? Or submit a package update for the dependency with a security label?

Let's just waste the limited time the VLC devs can spend (for free) on their project by making them chase after debian maintainers and other distros' maintainers... to get them to update a library that isn't even a VLC project... because debian decided to patch out the library version bundled with VLC in favor of their own outdated libebml package... to get a bug patched that wasn't even considered a security issue until recently...

Sorry, but this sounds ridiculous to me.

Re: About the “Security Issue” on VLC

#83

Post by skykooler »

virgilp wrote: post #17
jbk wrote: post #14

Earlier quoted context omitted.

> I really wonder where the CVE got their "attack vector: network" and CERT "remote: yes" classifications from. They always do that with VLC: even file can be on a playlist, and a playlist can be sent by email or over the web, with a link... So they classify all VLC bugs with network and remote.

By that token, is there ANY application where the attack vector is not 'network' and 'remote' is 'no'? Because I fail to think of any minimally-useful app that doesn't open external files.

Calculator?

Re: About the “Security Issue” on VLC

#84

Post by nemosaltat »

larrysalibra wrote: post #7
LeonM wrote: post #2

So none of the tech news websites contacted VideoLAN and published their articles without checking their source. I believe this sums up the problem with online news: being first matters most to news sites. It drives traffic. Accurate reporting comes second. I feel bad for VideoLAN, according to them the bug was in a 3rd party lib and was fixed 16 months ago.

News articles not checking sources is pretty standard. A few years ago I had a blog post about something regarding Apple picked up by the Hong Kong Free Press and then the New York Times. It ended up resulting in articles across hundreds of publications. The only publications that talked to me and Apple were the New York Times, the original Hong Kong Free Press and a CNN money reporter. Everyone else was just rewriti…

Excellent book. I particularly like his thoughts on the “link economy”- how links give credence to statements in an article despite the fact that they may not even link to a relevant or accurate source.

That said, I “read” a lot of of audiobooks and this one is self-narrated. I highly recommend the book, but don’t recommend Ryan Holiday as a narrator.

Re: About the “Security Issue” on VLC

#85

Post by fulafel »

jbk wrote: post #26
fulafel wrote: post #24

I think the VLC developers come off as pretty defensive in this. They flame the reporter for opening the issue on the issue tracker, but on the issue the reporter says that he got no response from the VLC security contact which he tried first. Then, they dismiss the vulnerability and flame the CVE assigners, because VLC themselves are shipping a distribution with the vuln fixed, even though many Linux distributions a…

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…

By defensive I don't mean mean everyone else is right, just that there seem to remain a problem that should be addressed (warranting a CVE ID), even if there were hyped headlines in the press and an email communication problem.

IMO it would be better PR to acknowledge the vulnerability and assume good faith on part of the reporter pending indications to the contrary. And maybe skip dismissing the Linux user base like this...

Re: About the “Security Issue” on VLC

#86

Post by Redoubts »

yjftsjthsd-h wrote: post #48
gsich wrote: post #43

Earlier quoted context omitted.

The library is not the newest one, so it is by definition, old.

Sorta, but most people mean "obsolete, shouldn't use" when they say old. For instance, postgres currently has 5 in-support versions going back to 9.4; are 9.4-10 "old"?

Postgres without upsert is definitely old.

Re: About the “Security Issue” on VLC

#87

Post by fulafel »

hs86 wrote: post #21

libebml is in the Ubuntu universe repository which means that it is not supported by Canonical. And in the Debian changelog for this package I don't see any mentions of a security issue that was fixed 16 months ago: https://metadata.ftp-master.debian.org/changelogs//main/libe... I am loosing more and more confidence that these "package the world and freeze everything in place" distros are the right choice for end use…

Ubuntu badly needs a mechanism for blacklisting vulnerable "universe" categorised software that handle untrusted data from the network. Or some other way of protecting users in these cases.

This is by far not the first time this happens, though good that there is a public outcry this time...

Re: About the “Security Issue” on VLC

#88

Post by effie »

cesarb wrote: post #75
tatersolid wrote: post #54

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? 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 used to be the norm, until a really bad (as in, remote code execution) vulnerability was found in zlib, which was bundled nearly everywhere. The lesson learned was that bundled third-party libraries are a security risk, and all major distributions changed their policies to allow them only in exceptional cases.

Could you give a reference for that rationale?

That does not seem to be the right lesson to be learned. They need to watch out for security holes and prepare fixes for both bundled lib and shared lib model.

The more likely reason for that change seems that it is less work to update single package than all packages. But this increases security risk, because now you're running obsolete versions of those other packages.

Re: About the “Security Issue” on VLC

#89

Post by Aissen »

It's funny jbk did a talk at Pass the Salt this year entirely prophesying this type of event (it's not the first time this happens…):

https://passthesalt.ubicast.tv/videos/vlc-and-security/

I took live notes (not nearly as colorful as the talk) here: https://anisse.astier.eu/pass-the-salt-2019-2.html

Re: About the “Security Issue” on VLC

#90

Post by wepple »

throwaway_391 wrote: post #32

Slightly offtopic, but are vulns related to overflows no longer pocced publicly or are there mitigating factors which make exploitation impossible (eg K/ASLR etc)? The specific CVE listings I'm referring to are: https://www.cvedetails.com/vulnerability-list/vendor_id-5842... https://www.cvedetails.com/vulnerability-list/vendor_id-26/p...

Building a PoC to prove you can get reliable code execution is typically 10x harder than finding an issue and patching it.

The modern approach is to assume that most types of memory corruption could be exploitable, and just patch.

Especially given that an inability for one person to reliably PoC does not mean it’s not exploitable; as soon as you say it’s not exploitable, Mark Dowd shows up and exploits the bug.

Post reply on HN