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…
About the “Security Issue” on VLC
31–40 of 174 posts
Re: About the “Security Issue” on VLC
#32The 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
#33I 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.
> 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
#34Earlier 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.]
Re: About the “Security Issue” on VLC
#35I 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…
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
#36I 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 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
#37I 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…
Re: About the “Security Issue” on VLC
#38I 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…
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
#39Earlier 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.
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.