5 ms·
I don't like the exchange with TheRegister: > TheRegister: FWIW we reported the VLC developers were skeptical. Happy to update our coverage accordingly. > Tho
by onli 7y ago
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 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.
- jbk 7y agoAn 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.
- onli 7y agoI 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.
- belorn 7y agoSince 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.
- effie 7y agoThe 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.
- arka2147483647 7y agoIn Linux distros, the Distribution is responsible for packages. DLC can't patch them themselves. So not DLC's fault.
- kalleboo 7y agoIs 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"?
- onli 7y agoMy point is a different one: If a user or a journalist installs the current version of the software and he runs a current distro it is not a surprise that he assumes a (security) flaw that manifests when using that program is caused by the program. The main project does not necessarily have to fix it themselves, but ideally would notify the distro (and that would make for a good response).
- jbk 7y agoa journalist is on Windows or mac. They could even chekc that it does not crash with the provided sample.
- kalleboo 7y agoAlthough in this case, The Register journalist was on Debian, they checked it and it crashed (because Debian packages an old version)
- rndgermandude 7y agohttps://www.theregister.co.uk/2019/07/23/remote_code_flaw_vlc/ 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.
- pdpi 7y agoI'd argue that, in a dynamically linked system, the onus in on the system maintainer, not the application developer, to fix these issues.
- jakear 7y agoAnd 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.
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- kuschku 7y agoIf you download the VLC build from VLC themselves, it won’t crash. It’s simply that Debian/Ubuntu patch VLC to use an older version of the library, which of course is broken and has the bug.