About the “Security Issue” on VLC
twitter.com
twitter.com
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.
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?
Because stonewalling is SOP for government bureaucracies when they screw up.
When you're the government the various systems the people you screwed have for recourse work slightly differently so stonewalling works better than spewing out a ton of deny and distract PR like corporations do.
FTFY
A lot of people seem to be under the impression that when you just privatize a government agency, it magically becomes better. It doesn't.
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.)
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.
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.
"A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may require the attacker: to perform target-specific reconnaissance; to prepare the target environment to improve exploit reliability; or to inject herself into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g. a man in the middle attack)."
But you could also argue 'Attack complexity' of any exploit which has per-os/arch exploits requires reconnaissance. There, I just boxed MS08-67 (which is arch-specific, iirc) as 'Attack Complexity: High' with pretty much any theoretical crypto attack which would cost billions to exploit :)
Lets not forget CVSS doesn't assess likelihood or business impact well (or at all) either. Your org is far more likely to get rekt if you do not enforce application whitelisting, compared to an intranet-exposed drupalgeddon vulnerability.
The economics of the industry drive this behavior - most reporters have a quota of stories they have to write per day and there's no time or budget to even email sources let alone sit around waiting for a reply.
If you want to read more about this, I recommend the book "Trust me, I'm lying" by Ryan Holiday.
That said, I “read” a lot of of audiobooks and this one is self-narrated. I highly recommend the book, but don’t recommend Ryan Holiday as a narrator.
i also tried listening to conspiracy, also by him, and it was much more enjoyable (he narrates, but the sound quality is much better).
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...
Thank you for your efforts in developing VLC, it is a great tool.
It shines bad light on the official institutions that they haven't checked back with you.
I've used VLC on all supported platforms for almost as long as it's been in existence: THANK YOU.
Please keep up the awesome work, VLC is a treasure.
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 Open Lawyer as well as Open Source!
I'm of the thinking that the only way media would get any education would be litigation. Sad I know, but that is the World they operate in. Why else do media outlets have lawyer departments.
Apologies.
@ you and any lawyers
I know you probably don't want to go to some long-term battle in the courts with any of these groups. What about a libel suit in small claims court against each one? I wonder if that's even possible. If so, start with one to keep time/costs down, then (if victorious) hit the others either one at a time or simultaneously. At the least, the wins raise you some funding while providing some small deterrence from them doing it again.
Has any American newspaper or person or politician on twitter been forced to retract exaggerated claims?
Seemingly.
https://digitalcommons.wku.edu/cgi/viewcontent.cgi?article=1...
I'm not sure, doesn't look like this would fall under their remit, but no definitive yes or no jumping out for me either.
https://en.wikipedia.org/wiki/Software_Freedom_Conservancy
Not a long litigation list either, so hard to see any comparable cases in the two instances listed.
So I'm going to lean against a no, but I'm not 100% sure upon this.
This problem has been around as long as more than one news outlet has been around... Getting the story first over getting the story right didn't get invented by online news.
Following the debunking of the story, what does Gizmodo do? Leave it on the front page and change the headline to "You Might Want to Uninstall VLC. Immediately [Updated]"
>You Might Want to Uninstall VLC. Immediately. [Updated: Maybe Not]
Is the current title...
Should have done that from the very beginning, as should have MITRE before publishing a CVE ID.
Failures all around on this one. Sorry you’re having such a shit morning, jbk, because of other people’s laziness.
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.
Indeed, and they've been doing the same thing with projects like jackson-databind. 10s of completely meaningless CVEs issued for each new deserialization gadget that someone finds and gets added to a blacklist designed to protect a known-unsafe use-case (deserializing user input whilst defaultTyping is enabled).
It causes a huge waste of resources on the blue side.
As someone who was recently a security engineer the treating as gospel is a real problem. In reviews of new CVE's you always ended up having to do the legwork to see if it was even relevant. Older CVE's I felt like usually were at least tied to something mostly concrete but the number of times I find the security report and it's just basically a valgrind/fuzzy lop output I am frustrated in the quality of reporting.
The other half of it is the journalists chasing clicks and researchers who name vulns to increase their status. That practice has really been a lot of crying wolf and it's starting to show. We had to create a special categories for vulnerabilities that were named/publicly visible and may or may not even be relevant to us just to respond to inquiries (especially things that were named but mediums on a NIST 90 day timeline but people expected resolved day 0-1).
I am loosing more and more confidence that these "package the world and freeze everything in place" distros are the right choice for end users.
https://security-tracker.debian.org/tracker/CVE-2019-13615
In this case, this hasn't yet been updated with the info from the VLC team, I expect it'll be marked ignore or not-vulnerable once that happens.
I don't know the real CVE for the libebml issue but it doesn't appear to be listed at https://security-tracker.debian.org/tracker/source-package/l... which means that the Debian security team aren't aware of it.
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.)
The distribution model has the advantage of single click install. Great for basic users, but you run outdated software, sometimes with well known security holes. For power users who can take some work in maintaining their system, it seems to me that your way - keeping up with the latest version of all software - gives you better security.
The only difference is that Arch updates their repos' packages as soon as a new version is available upstream (after some testing of course), while Ubuntu doesn't.
No surprise there. Those aren't really for desktop use. Most "stable" distros users are servers.
If you are a desktop user you probably want your new shiny Firefox or LibreOffice as soon as possible, so you run either a six month cadence (Ubuntu, Fedora) or rolling (Debian testing, SuSE Tumbleweed, Gentoo). The latter can have a bit of light breakage for time to time so the six month cadence is probably a better fit for most casual users.
If you're an enthusiast you want that (and most linux users are probably enthusiasts), but most people just want something to work and remain static and aren't remotely interested in whatever new experiment firefox is unleashing on users.
If you don't like frozen packages, why are you using Ubuntu LTS? Ubuntu provides an updated stable release every six months if you want something closer to rolling. But most Ubuntu users, not even desktop users, use that. The market is speaking, and it wants stable releases frozen for years at a time.
It is a contradiction to demand both.
This is by far not the first time this happens, though good that there is a public outcry this time...
Because it sounds like the VLC binary Ubuntu provides is linked against this unsupported and out-of-date library, whereas the VLC binaries the VLC folks themselves provide are linked against a fixed version of the library...
So the problem is VLC using unstable dependencies without a mature release cycle.
It's not a "old" version of Ubuntu its the latest LTS.
That's the point of LTS.
Alternatively (because libebml is "universe", that is, unsupported), stop ripping out maintained components from projects to "use system packages instead" which are not maintained.
It's stuff like this that makes Firefox and Pale Moon play hardball with distros that mess up their software. (nevermind that the Pale Moon devs aren't even trying to solve such things amicably)
tl;dr Avoid Ubuntu LTS because they don't maintain their packages properly.
Since then, both Debian and Ubuntu have acted the same: not knowing about the vulnerability, neither updated their [release] packages. Buster happened to have been updated before it was frozen for release. Stretch was not, and neither was 18.04.
> tl;dr Avoid Ubuntu LTS because they don't maintain their packages properly.
By your logic, you should also avoid Debian then, since they followed the same process here. What got updated and what didn't was merely an accident of calendar freeze dates.
At the time I write this, Debian stretch is still on 1.3.4-1 and hasn't been updated. Ubuntu 18.04 has now been updated.
It's true, I was looking at Debian testing & sid as possibilities but apparently they can't handle mass rebuilds very well and the recommended workaround is to just not update. So rolling distros only for me. (current NixOS)
https://passthesalt.ubicast.tv/videos/vlc-and-security/
I took live notes (not nearly as colorful as the talk) here: https://anisse.astier.eu/pass-the-salt-2019-2.html
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...
The modern approach is to assume that most types of memory corruption could be exploitable, and just patch.
Especially given that an inability for one person to reliably PoC does not mean it’s not exploitable; as soon as you say it’s not exploitable, Mark Dowd shows up and exploits the bug.
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.
... I guess there isn't one. According to VLC upstream it was fixed in libevml 1.3.6.
>The reporter is using Ubuntu 18.04, which is an old version of Ubuntu, and clearly has not all the updated libraries.
18.04 is an LTS version, many people (myself included) will be using this until 20.04 comes out next year! It is not old - it gets regular updates for both security and features - clearly the library for whatever reason is excluded.
IMHO, it's definitely time for this to be allowed.
But - they don't know. And the newspapers will not report it in a dramatic post like this one.
> 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.
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.
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.
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"?
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.
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
Yes, managing dependencies is absolutely the developers’ responsibility. Choosing only well-maintained dependencies is part of that management.
> Shouldn't that be the responsibility of the distribution?
Not completely. You decided to take that dependency to save yourself effort. The distribution did not make that choice. The distribution may not even have a maintainer anymore. You as the developer need to do what you can ensure the “right” version of your dependency is used. This means talking to packagers and distros, and even (gasp) submitting package updates yourself if you rely on a dependency.
Or just bundle local versions of dependencies yourself and stop relying on shared libraries.
That’s what VLC did, Ubuntu/Debian patched VLC to instead use their, older, shared libraries.
I’m not sure what course of action you suggest for developers in such a situation
Talk to somebody at Debian? Or submit a package update for the dependency with a security label?
Sorry, but this sounds ridiculous to me.
That used to be the norm, until a really bad (as in, remote code execution) vulnerability was found in zlib, which was bundled nearly everywhere. The lesson learned was that bundled third-party libraries are a security risk, and all major distributions changed their policies to allow them only in exceptional cases.
That does not seem to be the right lesson to be learned. They need to watch out for security holes and prepare fixes for both bundled lib and shared lib model.
The more likely reason for that change seems that it is less work to update single package than all packages. But this increases security risk, because now you're running obsolete versions of those other packages.
Which I understand as a pragmatic solution, but it is far from clear that this gives users more security.
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.
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.
- the reporter never contacted us, we have a clear process and a bounty program. We checked again, he never did.
- we receive and process all security issues privately: we fixed 31 of them in the last update. And miracly, the other reporters managed to contact us.
- Linux is the smallest OS for VLC.
- 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!"
- The CVE number of 9.8 makes no sense. How do you even exploit this crash?
- VLC has DEP and ASLR activated everywhere. How do you execute code with this read issue?
I want applications to be packaged by my distribution. Updates are up to maintainers (dependencies included), as it has always been.
If MITRE wants to assign a CVE, warning people that they need an updated lib, that's fine. The issue is the trustworthy and handling of CVEs (... plus reporters).
Patching for an older version of libebml is not an issue if that library is not vulnerable (that's why folks use LTS and stable). Want maintainers to know there's a vulnerability? Publish a CVE _for libebml_.
IMO it would be better PR to acknowledge the vulnerability and assume good faith on part of the reporter pending indications to the contrary. And maybe skip dismissing the Linux user base like this...
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.
You can't just publish information harmful to public and say "well I'm a researcher, so I can do anything I want". Publishing instructions to bypass important security restrictions that people rely on is often harmful and may be even illegal in some countries, for good reason - to protect the people.
>You can't just publish information harmful to public
It’s simply ridiculous to describe full disclosure like that.
But dropping a 0day irresponsibly can lead to actual impact - what happens if a good person is persecuted, or executed because of the information you disclosed publicly? What about a hundred. Or a thousand?
By not contacting the developer first, you're acting in bad faith. This opens you up to all kinds of legal liabilities, not to mention the social exclusion that will occur.
There’s no implicit “bad faith” in full disclosure or even the sale of weaponized 0day exploits.
Charity is nice, but I’m not going to insist that you donate your whole paycheck!
Do you want ham-fisted regulations? Because that's how you get ham-fisted regulations.
Lawmakers analogize. All it takes is for some bright representative to think that "vulnerability disclosures" are more akin to "burglary tools" than to public service announcements to justify criminalizing third-party security research (or the resulting disclosures).
It doesn't even take that much - throwing around terms like "bad faith" and "legal liabilities" suffices to create a hostile legal regime through common law torts. I'm okay with socially condemning unilateral disclosure as a likely assholeish thing to do, as long as we acknowledge that being an asshole is perfectly legal.
I'm admittedly not up to speed on this particular soap opera, but it seems like the real blameful parties here are Gizmodo et al - scraping the bottom of the barrel for raw technical tidbits, and then escalating them into sensationalist "news" narrative rather than performing any sort of responsible interpretation.