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

71–80 of 174 posts

Re: About the “Security Issue” on VLC

#71

Post by lol768 »

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

> treat reporting as gospel and don't validate

Indeed, and they've been doing the same thing with projects like jackson-databind. 10s of completely meaningless CVEs issued for each new deserialization gadget that someone finds and gets added to a blacklist designed to protect a known-unsafe use-case (deserializing user input whilst defaultTyping is enabled).

It causes a huge waste of resources on the blue side.

Re: About the “Security Issue” on VLC

#72

Post by tatersolid »

kuschku wrote: post #59
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’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?

Re: About the “Security Issue” on VLC

#74

Post by rndgermandude »

kalleboo wrote: post #50
jbk wrote: post #46

Earlier quoted context omitted.

a journalist is on Windows or mac. They could even chekc that it does not crash with the provided sample.

Although in this case, The Register journalist was on Debian, they checked it and it crashed (because Debian packages an old version)

https://www.theregister.co.uk/2019/07/23/remote_code_flaw_vl...

The article writer checked it using an outdated version of VLC (3.0.7 instead of 3.0.7.1), which should have at the very least warranted a closer look into whether the official latest release has the same issue, or if it was a problem with the version packaged by his distro of choice.

The "update" The Register did, which really should be a "correction", is half-assed and well hidden below the fold at the end of the article.

Re: About the “Security Issue” on VLC

#75

Post by cesarb »

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

Re: About the “Security Issue” on VLC

#76

Post by p49k »

Gizmodo posts the headline on their front page, "You Might Want to Uninstall VLC. Immediately"

Following the debunking of the story, what does Gizmodo do? Leave it on the front page and change the headline to "You Might Want to Uninstall VLC. Immediately [Updated]"

Re: About the “Security Issue” on VLC

#77

Post by lucideer »

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.

This is worse though. Neither MITRECorp, CERT-Bund.de nor NIST are tech news websites or journalistic publications. This is beyond being an issue with online news: this is an issue with security organisations actively ignoring their own policies due—seemingly—to an institutional disregard for a non-commercial FOSS project.

Re: About the “Security Issue” on VLC

#78

Post by effie »

thegeomaster wrote: post #68
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…

> 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 version of all software - gives you better security.

Re: About the “Security Issue” on VLC

#79

Post by plopz »

jokowueu wrote: post #61

>Yes, so your issue is your distribution is not up-to-date, not VLC. I've always found it odd that many of the packages on certain linux distributions were old . Like how one time the latest openvpn version on the latest Ubuntu release was a year old.

Debian 8 is still on php 5.6 which is EOL, even if you upgrade to debian 9 you would be on php 7.0 which is also EOL.

Re: About the “Security Issue” on VLC

#80

Post by jakear »

pdpi wrote: post #44
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…

I'd argue that, in a dynamically linked system, the onus in on the system maintainer, not the application developer, to fix these issues.

And in this case, it was apparently the system maintainer that introduced the bugs. (By patching VLC to use a shared, outdated, and insecure library instead of the one the developers shipped it with).

This puts a very bad taste in my mouth re the GNU+Linux ecosystem. Being able to specify “use this version at minimum” is a critical feature of any dependency management system, and it seems like distributions don’t really provide that.

Post reply on HN