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.
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.)
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.
"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.
News articles not checking sources is pretty standard. A few years ago I had a blog post about something regarding Apple picked up by the Hong Kong Free Press and then the New York Times. It ended up resulting in articles across hundreds of publications. The only publications that talked to me and Apple were the New York Times, the original Hong Kong Free Press and a CNN money reporter. Everyone else was just rewriting other posts.
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.
Excellent book. I particularly like his thoughts on the “link economy”- how links give credence to statements in an article despite the fact that they may not even link to a relevant or accurate source.
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 expect a little bit of personal responsibility at this point. You simply should not believe what you read in the news. It's either not researched at all or just false.
It will sound boring quickly, but I also want to thank you for developing VLC. Great work. Amazing work. You have many devoted fans all around the world.
I don't know if it matters at all, but after hearing the news, I still fired up VLC to watch a few videos because I feel you guys have built up enough credibility and credit that such an extraordinary claim would require extraordinary evidence (which I wasn't seeing) and if there was a problem, your team would fix it ASAP.
Please keep up the awesome work, VLC is a treasure.
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 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.
I didn't express that well: In copyright terms, if you compete with commercial; or acquire money via a side-channel then it's "commercial" ... what I was trying to express was that it occupies a space where it's serious software and that damage to it's reputation should be treated just as seriously as damage to a sold product from a for-profit.
Yes, hence they don't have a lawyer ontap, which was kinda the point I was making. The education (what I'm going to call it) that they could bestow upon these bismershing media outlets, would fund much Open Source work for VLC.
You say “they don’t have a lawyer” I don’t know if you realize you’re addressing the lead developer and president of VLC. I think he may be quite a bit more aware of his org’s ability and desire to retain legal counsel than all of us.
Thanks for your hard work on VLC. I love it. Throwing you a quick donation so you have something good happening during an otherwise rough time.
@ 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.
Remember the Bloomberg Supermicro story? If a billion-dollar company cannot get Bloomberg to retract their stories, what chance does an open source project have?
Has any American newspaper or person or politician on twitter been forced to retract exaggerated claims?
This is worse though. Neither MITRECorp, CERT-Bund.de nor NIST are tech news websites or journalistic publications. This is beyond being an issue with online news: this is an issue with security organisations actively ignoring their own policies due—seemingly—to an institutional disregard for a non-commercial FOSS project.
Suggest everyone here pick a couple of news agencies who propagated this crap and write to the editors admonishing their shoddy fact-checking. I emailed two this morning.
> I believe this sums up the problem with online news: being first matters most to news sites. It drives traffic. Accurate reporting comes second.
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.
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
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.
Not allowing CNA seems to be the biggest issue. Long time ago we had issues where getting a new cve for an open source project was really rare and hard to achieve. Now anyone who asks gets one without validation. Two extremes, likely due to lack of resources, but they won't share the load...
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.
I think that this CVE issuance problem is getting worse recently where as in prior years there was just a smaller volume of CVE's being assigned. This VLC issue is the kind of CVE that could have been resolved by looking into it (or better assigned/described), and instead turned into a problem. There are also a string of people using security fuzzers to find issues but instead of them being triaged with security in mind they are getting CVE's issued. Some of the CVE's after investigation are test/utilities, pieces of code that are uncommon to be distributed, and a couple times code that is never called at all and was a function that never got cleaned up but when isolated had a stack overflow.
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).
Just that Ubuntu apparently forgot about the "S" part of "LTS", or they could have updated that package.
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)
The package in Debian was updated four days before Ubuntu 18.04 was released. That's why the update didn't make 18.04 "automatically".
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.
> By your logic, you should also avoid Debian then
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)
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"?
9.4 is definitely "old". You can use it if you want, and it has support (for now), but it's not a good idea to base new projects on it unless they're likely short term. ;)
> 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.
I 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.
Since 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.
The 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.
Is 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"?
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).
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.
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
> Is it now the responsibility of every piece of software to check the versions of every library they're linked to for security patches?
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.
Let's just waste the limited time the VLC devs can spend (for free) on their project by making them chase after debian maintainers and other distros' maintainers... to get them to update a library that isn't even a VLC project... because debian decided to patch out the library version bundled with VLC in favor of their own outdated libebml package... to get a bug patched that wasn't even considered a security issue until recently...
> Or just bundle local versions of dependencies yourself and stop relying on shared libraries.
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.
Thanks, this confirms my impression - the distributions are prone to think "we want to organize the software, but keeping up-to-date upstream software is too much work, so we'll use shared libraries and freeze everything to older versions".
Which I understand as a pragmatic solution, but it is far from clear that this gives users more security.
And 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.
libebml 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 users.
> 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.
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.)
Canonical probably does care less than in their desktop golden years, now they are perhaps focusing on the server os market (cloud).
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.
What do you mean? Arch works the same way as Ubuntu; there's a package manager, you use it to install software from the system repositories. `apt-get install vlc` is no easier or more user friendly than `pacman -S vlc`. I imagine gnome-software even works it does in Ubuntu, though I haven't tried using it.
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.
I meant the LTS model such as Ubuntu 18.04 gives you old version software with the possibility of worse functionality and more security holes. Arch may be more up-to-date than Ubuntu, but it isn't in the same category; it is not LTS, and it is not as widespread.
I was mostly responding to the part about how "The distribution model has the advantage of single click install". What's the difference in how "single click" installation can be between rolling and LTS?
The point is classic distributions which support their product for a long time (Debian, Ubuntu,RHEL,Centos) are easier to use for basic users you can meet on street. With Arch or Gentoo, you are right that there is a package manager which makes installation of software easier, but the system is not easy to use for BFUs. When problems with installation/upgrades arise (which is more likely for Arch/Gentoo), you are expected to spend some time becoming proficient GNU/Linux user who resolves things in command line.
Citation needed on the number of problems, assuming the classic system is actually being updated from release to release so it can continue to receive critical updates.
> at least for desktop use-cases, what exactly is gained
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 are a desktop user you probably want your new shiny Firefox or LibreOffice as soon as possible
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.
As much as I hate to say it, that ship has probably sailed. If you surf the web in 2019 you're likely using javascript and you need an updated web browser. The attack surface on those things are enormous.
I'd agree with you there. I run Arch on my home computer and update fully pretty much every time I use it (because it's so fast to update everything) and I think I've only had 1 breaking change in ~5 years.
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.
I run servers on Ubuntu LTS, my personal machines on Arch. Frozen packages are great for servers but for desktops I just don't see the benefit. Hence my comment.
Ubuntu badly needs a mechanism for blacklisting vulnerable "universe" categorised software that handle untrusted data from the network. Or some other way of protecting users in these cases.
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...
It looks like the problem is that their is no stable version with any long term commitments to security fixes, at least I couldn't find any mention of one on the website or github page. I'm can't see any release branches on github.
So the problem is VLC using unstable dependencies without a mature release cycle.
I 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 and presumably other distributors of VLC remain vunerable - a situation clearly requireing vulnerability coordination and a CVE assignment.
- 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?
Since this is tarnishing your brand, maybe ask Ubuntu to cease shipping "VLC" if they do such a half-assed job (enough effort to replace integrated libraries with system packages, not enough effort to maintain those packages)?
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).
My impression is that VLC did issue an update to use a more recent version of libebml, but Ubuntu/Debian maintainers patched it to use universe’s outdated version (which they don’t even maintain!)
Yes! A glaring example of dependency hell (in Debian words "incompatible library changes with reverse dependencies").
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_.
By defensive I don't mean mean everyone else is right, just that there seem to remain a problem that should be addressed (warranting a CVE ID), even if there were hyped headlines in the press and an email communication problem.
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...
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.
Everybody, including researchers, has a duty to publish things responsibly and if necessary, withhold the publication. Despite the economical incentives, the moral responsibility is to research and harden systems, not to publish whatever and build a resume.
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.
I did not say duty to work for free, but duty to observe some restrictions and weighing positive/negative impacts of your publications on society if you choose to work in that domain.
I've heard some interesting arguments about publicly dropping 0days to make organisations pull their heads in - Places like Microsoft which historically weren't -great- at security 'deserved' it. I'm not saying that argument is right or wrong, but it was interesting nonetheless.
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 choosing to disclose publicly rather than privately, they’re willfully giving (in their minds) a RCE on every VLC installation to whomever reads the bug logs. I think most people would agree that’s not right.
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.
Oh this trope again. I am no vendor and I fully support the idea that security researchers coordinate their publication activities with affected parties.
Great, me too. But I also fully support the idea that people should be allowed to do whatever the fuck they want with their work product. (within the limits of the law, of course)
Charity is nice, but I’m not going to insist that you donate your whole paycheck!
> I also fully support the idea that people should be allowed to do whatever the fuck they want with their work product. (within the limits of the law, of course)
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).
> All it takes is for some bright representative to think that "vulnerability disclosures" are more akin to "burglary tools" than to public service announcements
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.
Slightly offtopic, but are vulns related to overflows no longer pocced publicly or are there mitigating factors which make exploitation impossible (eg K/ASLR etc)?
Building a PoC to prove you can get reliable code execution is typically 10x harder than finding an issue and patching it.
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.
Except if I missed something in my quick research, there doesn't seem to have been a CVE for libebml when it was fixed 16 months ago. So it's really not surprising that LTS distros don't have the fix...
>Yes, so your issue is your distribution is not up-to-date, not VLC.
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.
Debian 10 is running 7.3, thankfully. But their LTS runs for 5 years and 7.3 will be EOL about 7 months before Buster and active support dropped about 17 months before. And PHP 7.4 is due out in November/December. So Buster will be outdated with its PHP release 6 months after release.
Gizmodo posts the headline on their front page, "You Might Want to Uninstall VLC. Immediately"
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]"
Its amazing how a title can have two entirely contradictory, non committal claims telling you to do a thing, and yet tell me absolutely nothing useful.
I read gizmodo every once in a while for mild entertainment. I have never considered it, or anything related to Kinja, to be trustworthy in any shape or form.
Lifehacker (which is part of the same blog network) posted "Wait Before Uninstalling VLC from Your Computer." They're trying to get all the clicks from every angle.
Just to clarify things: CVSS scores are almost completely meaningless and nobody should take them seriously. They're a Ouija Board that can be made to say anything.
Completely OT: does anyone else find this style of posting stuff on a very long twitter thread hard to read, and somewhat worrying in terms of dependency on a proprietary platform? Why can't this be upfront on the videolan.org homepage and just linked from a single tweet?
I know about that, I was more interested in the political point of being beholden to a proprietary platform. I think that is especially important for one of the most widely installed open source apps (on non-geeks computers).
>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.
They aren't blaming you for using the LTS version, and they aren't blaming Ubuntu for having an LTS version. The blame is (implicitly) on Ubuntu for not making sure the libraries their LTS version ships are up to date with the latest security patches. VLC itself isn't vulnerable - the problem is that some distributions are compiling it themselves with old libraries, which is 100% their own fault.
gizmodo.com.au still shows "You Might Want To Uninstall VLC. Right Now. Immediately." in their title. This highlights the untrustworthiness of most "news" today, be it software, politics or business related. It's unbelievable how poorly researched articles can damage people and businesses alike. I think is this is one of the biggest pain points of today's world, and it needs solving fast.
173 comments
[ 3.0 ms ] story [ 182 ms ] threadI 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.
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).
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)
> 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.
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.
- 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.
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 guess there isn't one. According to VLC upstream it was fixed in libevml 1.3.6.
https://trac.videolan.org/vlc/ticket/22474#comment:21
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.
IMHO, it's definitely time for this to be allowed.
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.
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
But - they don't know. And the newspapers will not report it in a dramatic post like this one.
https://twitter.com/videolan/status/1153963312981389312
to:
https://threadreaderapp.com/videolan/status/1153963312981389...
>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.