About the “Security Issue” on VLC • Hacker News Board

Re: About the “Security Issue” on VLC

#91

Post by effie » Wed, Jul 24, 2019, 1:54 PM UTC

belorn wrote: post #36

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…

Since we are talking about debian, what bug numbers is involved and which package does it belong to. The nature of dynamic loaded libraries and package management system is that bugs will end up at the developer who manage the code that has the bug, rather than the developer who has users that get effected by the bug. It look like blame shifting but I don't see how you could have it any other way.

The other way would be that writers check for correctness of what they're writing with the impacted party (VLC). Distributions watch out and look for security holes in their packages such as libebml and then issues fixes as soon as possible. Security bug reporters behave more responsibly in that they talk authors of the package first, then go cash in their piece of fame.

Re: About the “Security Issue” on VLC

#92

Post by fernandotakai » Wed, Jul 24, 2019, 2:02 PM UTC

nemosaltat wrote: post #84

larrysalibra wrote: post #7

Earlier quoted context omitted.

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.

i've found that trust me i'm lying was horribly recorded (at least on audible) --i tried listening to it twice, and just couldn't.

i also tried listening to conspiracy, also by him, and it was much more enjoyable (he narrates, but the sound quality is much better).

Re: About the “Security Issue” on VLC

#93

Post by tgragnato » Wed, Jul 24, 2019, 2:03 PM UTC

jakear wrote: post #81

tgragnato wrote: post #58

Earlier quoted context omitted.

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

Yes! A glaring example of dependency hell (in Debian words "incompatible library changes with reverse dependencies").

Patching for an older version of libebml is not an issue if that library is not vulnerable (that's why folks use LTS and stable). Want maintainers to know there's a vulnerability? Publish a CVE _for libebml_.

Re: About the “Security Issue” on VLC

#94

Post by cesarb » Wed, Jul 24, 2019, 2:03 PM UTC

effie wrote: post #88

cesarb wrote: post #75

Earlier quoted context omitted.

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

I don't recall where the original discussions following the zlib incident were, but here is the current rationale from one major distribution: https://fedoraproject.org/wiki/Bundled_Libraries

Re: About the “Security Issue” on VLC

#95

Post by bzbarsky » Wed, Jul 24, 2019, 2:05 PM UTC

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…

Is VLC also in the universe repository?

Because it sounds like the VLC binary Ubuntu provides is linked against this unsupported and out-of-date library, whereas the VLC binaries the VLC folks themselves provide are linked against a fixed version of the library...

Re: About the “Security Issue” on VLC

#96

Post by effie » Wed, Jul 24, 2019, 2:05 PM UTC

ryanlol wrote: post #70

throwaway_391 wrote: post #35

Earlier quoted context omitted.

Most / all software has a disclosure policy, send your vulns privately and provide/negotiate a public disclosure date. Not doing so is an asshole move. In this case, the solution would be to track down distributions which did not package the software and (privately) disclose to them that the relevant lib needs updating.

>Not doing so is an asshole move. Dictating how researchers should choose to publish their work product is an asshole move. If someone chooses to share their work product with you privately, that's very charitable of them. It's not reasonable to expect charity.

Everybody, including researchers, has a duty to publish things responsibly and if necessary, withhold the publication. Despite the economical incentives, the moral responsibility is to research and harden systems, not to publish whatever and build a resume.

You can't just publish information harmful to public and say "well I'm a researcher, so I can do anything I want". Publishing instructions to bypass important security restrictions that people rely on is often harmful and may be even illegal in some countries, for good reason - to protect the people.

Re: About the “Security Issue” on VLC

#97

Post by effie » Wed, Jul 24, 2019, 2:13 PM UTC

cesarb wrote: post #94

effie wrote: post #88

Earlier quoted context omitted.

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.

I don't recall where the original discussions following the zlib incident were, but here is the current rationale from one major distribution: https://fedoraproject.org/wiki/Bundled_Libraries

Thanks, this confirms my impression - the distributions are prone to think "we want to organize the software, but keeping up-to-date upstream software is too much work, so we'll use shared libraries and freeze everything to older versions".

Which I understand as a pragmatic solution, but it is far from clear that this gives users more security.

Re: About the “Security Issue” on VLC

#98

Post by mort96 » Wed, Jul 24, 2019, 2:16 PM UTC

effie wrote: post #78

thegeomaster wrote: post #68

Earlier quoted context omitted.

> I am loosing more and more confidence that these "package the world and freeze everything in place" distros are the right choice for end users. I'm there with you. I use a rolling distro (Arch) and I update all packages to the latest versions whenever I'm bored. I do this because I can't remember the last time something broke this way. I've been doing that for ~6 years on 3 different machines. On the other hand, a…

Canonical probably does care less than in their desktop golden years, now they are perhaps focusing on the server os market (cloud). The distribution model has the advantage of single click install. Great for basic users, but you run outdated software, sometimes with well known security holes. For power users who can take some work in maintaining their system, it seems to me that your way - keeping up with the latest…

What do you mean? Arch works the same way as Ubuntu; there's a package manager, you use it to install software from the system repositories. `apt-get install vlc` is no easier or more user friendly than `pacman -S vlc`. I imagine gnome-software even works it does in Ubuntu, though I haven't tried using it.

The only difference is that Arch updates their repos' packages as soon as a new version is available upstream (after some testing of course), while Ubuntu doesn't.

Re: About the “Security Issue” on VLC

#99

Post by justinclift » Wed, Jul 24, 2019, 2:21 PM UTC

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

9.4 is definitely "old". You can use it if you want, and it has support (for now), but it's not a good idea to base new projects on it unless they're likely short term. ;)

Re: About the “Security Issue” on VLC

#100

Post by jakear » Wed, Jul 24, 2019, 2:33 PM UTC

ryanlol wrote: post #70

throwaway_391 wrote: post #35

Earlier quoted context omitted.

Most / all software has a disclosure policy, send your vulns privately and provide/negotiate a public disclosure date. Not doing so is an asshole move. In this case, the solution would be to track down distributions which did not package the software and (privately) disclose to them that the relevant lib needs updating.

>Not doing so is an asshole move. Dictating how researchers should choose to publish their work product is an asshole move. If someone chooses to share their work product with you privately, that's very charitable of them. It's not reasonable to expect charity.

by choosing to disclose publicly rather than privately, they’re willfully giving (in their minds) a RCE on every VLC installation to whomever reads the bug logs. I think most people would agree that’s not right.