Live data from Hacker News

About the “Security Issue” on VLC

twitter.com

11–20 of 174 posts

Re: About the “Security Issue” on VLC

#11
post #3
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.

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

Re: About the “Security Issue” on VLC

#12
post #3
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.

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

I really wonder where the CVE got their "attack vector: network" and CERT "remote: yes" classifications from.

Even on vulnerable systems this seems to have been a local issue (or do they do that for anything that might potentially pull malicious files from outside sources? Sounds kind of backwards.)

Re: About the “Security Issue” on VLC

#13

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.

Re: About the “Security Issue” on VLC

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

I really wonder where the CVE got their "attack vector: network" and CERT "remote: yes" classifications from. Even on vulnerable systems this seems to have been a local issue (or do they do that for anything that might potentially pull malicious files from outside sources? Sounds kind of backwards.)

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

Re: About the “Security Issue” on VLC

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

I really wonder where the CVE got their "attack vector: network" and CERT "remote: yes" classifications from. Even on vulnerable systems this seems to have been a local issue (or do they do that for anything that might potentially pull malicious files from outside sources? Sounds kind of backwards.)

I guess they will change them silently at some point. It's more or less obvious they don't check the reports.

Re: About the “Security Issue” on VLC

#16
post #10
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.

> So none of the tech news websites contacted VideoLAN and published their articles without checking their source. Actually, one did: numerama. That's all. > I feel bad for VideoLAN, according to them the bug was in a 3rd party lib and was fixed 16 months ago. My night and morning have been difficult, as you can imagine...

I'm sorry that you're having a bad couple of days thanks to shitty journalism.

Thank you for your efforts in developing VLC, it is a great tool.

Re: About the “Security Issue” on VLC

#17
post #14

Earlier quoted context omitted.

I really wonder where the CVE got their "attack vector: network" and CERT "remote: yes" classifications from. Even on vulnerable systems this seems to have been a local issue (or do they do that for anything that might potentially pull malicious files from outside sources? Sounds kind of backwards.)

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

Re: About the “Security Issue” on VLC

#19
post #13

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.

Why can't you be an authority of your CVEs without consulting an American gov agency? I'm sure, VLC org is way more trustworthy for nine out of ten people on the Earth.

Re: About the “Security Issue” on VLC

#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, the issue is that a lib VLC uses is not up-to-date, and it just happens that VLC be installed on a distribution, as is normal. It can't run on bare metal. If I understand https://tracker.debian.org/pkg/libebml correctly it is possible the issue here is that oldstable Debian did not receive a (security?) update for libebml. But this still affects the users of the program. It's still something that could be justified to notify users about.

But I understand the frustration about not being contacted, and I understand the project does not want to be seen as responsible for this if the fault lies with Debian. And it's absolutely possible the CVE on VLC are wrong, I remember being surprised a few times about their strange severity. But still. I don't like this blame shifting. If users do not run a unsupported distribution it is not completely unreasonable to assume his falls into the security sphere of the main project, VLC.

Post reply on HN