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.
About the “Security Issue” on VLC
61–70 of 174 posts
Re: About the “Security Issue” on VLC
#62Re: About the “Security Issue” on VLC
#63So 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...
Re: About the “Security Issue” on VLC
#64Earlier quoted context omitted.
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.
AC not about the attacker, but the configuration of the component being assessed.
Re: About the “Security Issue” on VLC
#65Earlier quoted context omitted.
My 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).
Your post said "notify users about", which is where my comment came from. Notifying distros is something they could do, but how many/which distros do they have to notify? It seems like it could be a massive job in itself. Hence my edit :p
Re: About the “Security Issue” on VLC
#66> The reporter is using Ubuntu 18.04, which is an old version of Ubuntu, and clearly has not all the updated libraries. It's not a "old" version of Ubuntu its the latest LTS.
Re: About the “Security Issue” on VLC
#67Re: About the “Security Issue” on VLC
#68libebml 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'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 lot of my friends use Ubuntu as their main OS and they constantly have mysterious issues with software, trouble installing stuff (a ton of things require binary-only vendor-run PPAs which then often have out-of-date versions), etc.
So I'm wondering, at least for desktop use-cases, what exactly is gained there? I would've thought that freezing all packages and issuing a release would allow a much more rigorous QA process and make the system rock solid. But somehow a huge company (Canonical) cannot make a system that is as stable as orders of magnitude less popular, volunteer-run rolling distribution.
Something just doesn't add up to me there. It could be a bias of my sample, or Canonical just not caring much about the desktop experience anymore. (I run a lot of machines on Ubuntu LTS and for the server-side it's pretty good.)
Re: About the “Security Issue” on VLC
#69Earlier quoted context omitted.
The library is not the newest one, so it is by definition, old.
Sorta, but most people mean "obsolete, shouldn't use" when they say old. For instance, postgres currently has 5 in-support versions going back to 9.4; are 9.4-10 "old"?
Re: About the “Security Issue” on VLC
#70I 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.
Dictating how researchers should choose to publish their work product is an asshole move.
If someone chooses to share their work product with you privately, that's very charitable of them. It's not reasonable to expect charity.