Live data from Hacker News

About the “Security Issue” on VLC

twitter.com

31–40 of 174 posts

Re: About the “Security Issue” on VLC

#31
post #30
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.

If VLC was a commercial product, this would be a lawyer time for effectively damaging reputation based upon lies and would see many media outlet dragged over the coals. VLC is not a commercial product, but equally still took the same impact from this and as we know, many end-user will be oblivious of any retraction as the case with many media retractions/corrections that get buried and do not traction. Maybe we need…

[Edit, see below.]

Re: About the “Security Issue” on VLC

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

Re: About the “Security Issue” on VLC

#33
post #23
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…

An issue on one or two Linux distribution for a OOB-read crash is very very different from "VLC vulnerable on all machines, uninstall now!" Especially, since the very very large majority of VLC users are not on Linux, but using binaries.

I agree. Main issue seems reasonable. Still, the environment that VLC lives in includes Debian oldstable, and this exchange feels to me like not hitting the right balance between accepting that and moving the justified blame to the distro. The reporter was not unreasonable after all.

> Especially, since the very very large majority of VLC users are not on Linux, but using binaries.

It's also apart from BSD pretty much the only OS where security issues like this matter, since closed source OS like Windows are insecure by default. I'm aware this is an ideological standpoint and not universally accepted.

Re: About the “Security Issue” on VLC

#34
post #30

Earlier quoted context omitted.

If VLC was a commercial product, this would be a lawyer time for effectively damaging reputation based upon lies and would see many media outlet dragged over the coals. VLC is not a commercial product, but equally still took the same impact from this and as we know, many end-user will be oblivious of any retraction as the case with many media retractions/corrections that get buried and do not traction. Maybe we need…

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

Re: About the “Security Issue” on VLC

#35
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…

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.

Re: About the “Security Issue” on VLC

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

Re: About the “Security Issue” on VLC

#37
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…

In Linux distros, the Distribution is responsible for packages. DLC can't patch them themselves. So not DLC's fault.

Re: About the “Security Issue” on VLC

#38
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 determine? edit2: Or is that common method "file a CVE"?

Re: About the “Security Issue” on VLC

#39
post #17
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.

CVSS is an insane rating system made for a simpler time by antiquated practices which doesn't account for many factors either well if at all.

Hover your mouse over each button https://www.first.org/cvss/calculator/3.0 . There's Attack complexity 'low' and 'high', for instance. You're either a script kiddie or have a two billion dollar exploitation budget and all the human resources you need, but nothing in between.

Post reply on HN