VLC Developer Debunks Reports of 'Critical Security Issue' In Open Source Media Player (portswigger.net) 80
New submitter Grindop53 shares a report: Widespread reports of a "critical security issue" that supposedly impacted users of VLC media player have been debunked as "completely bogus" by developers. Earlier this week, German computer emergency response team CERT-Bund -- part of the Federal Office for Information Security (BSI) -- pushed out an advisory warning network administrators and other users of a high-impact vulnerability in VLC. It seems that this advisory can be traced back to a ticket that was opened on VLC owner VideoLAN's public bug tracker more than four weeks ago. The alleged heap-based buffer overflow flaw was disclosed by a user named "topsec(zhangwy)," who stated that a malicious .mp4 file could be leveraged by an attacker to take control of VLC media player users' devices. The issue was flagged as high-risk on the CERT-Bund site, and the vulnerability was assigned a CVE entry (CVE-2019-13615).
However, according to VideoLAN president Jean-Baptiste Kempf, the exploit does not work on the latest VLC build. In fact, any potential issues relating to the vulnerability were patched more than a year ago. "There is no security issue in VLC," Kempf told The Daily Swig in a phone conversation this morning. "There is a security issue in a third-party library, and a fix was pushed [out] 18 months ago." When asked how or why this oversight generated so much attention, Kempf noted that the reporter of the supposed vulnerability did not approach VideoLAN through its security reporting email address. "The guy never contacted us," said Kempf, who remains a lead developer at the VLC project. "This is why you don't report security issues on a public bug tracker." Kempf and his team were unable to replicate the issue in the latest version of VLC, leading many to believe that the bug reporter was working on a computer running an outdated version of Ubuntu. "If you report a security issue, at least update your Linux distribution," Kempf said.
However, according to VideoLAN president Jean-Baptiste Kempf, the exploit does not work on the latest VLC build. In fact, any potential issues relating to the vulnerability were patched more than a year ago. "There is no security issue in VLC," Kempf told The Daily Swig in a phone conversation this morning. "There is a security issue in a third-party library, and a fix was pushed [out] 18 months ago." When asked how or why this oversight generated so much attention, Kempf noted that the reporter of the supposed vulnerability did not approach VideoLAN through its security reporting email address. "The guy never contacted us," said Kempf, who remains a lead developer at the VLC project. "This is why you don't report security issues on a public bug tracker." Kempf and his team were unable to replicate the issue in the latest version of VLC, leading many to believe that the bug reporter was working on a computer running an outdated version of Ubuntu. "If you report a security issue, at least update your Linux distribution," Kempf said.
Re: (Score:2)
Is Kempf right? (Score:2)
"If you report a security issue, at least update your Linux distribution," Kempf said.
Will current LTS editions of Ubuntu and other popular distros actually have the most current version of VLC available in their package managers? In my previous experience with Ubuntu (many years ago) this wasn't always the case.
Re:Is Kempf right? (Score:4, Informative)
After a little checking I suspect that Kempf is being disingenuous here.
The bug ticket at https://trac.videolan.org/vlc/... [videolan.org] shows the bug in "VLC media player 4.0.0-dev Otto Chriek (revision 3426d7b)". I thought that was a little odd, version 4.0.0-dev, given that the official VLC download page, https://www.videolan.org/vlc/ [videolan.org], lists the current version as 3.0.7.1.
So, I checked the videolan/vlc GitHub repo, https://github.com/videolan/vl... [github.com], and you can see that commit is from 19 June 2019.
Re: (Score:3)
As j-b has said in the bugreport, the bug is in external library "libebml".
If you have an old version of the library installed on the system, any version of VLC that is linked to it may be affected.
This is why j-b said that you should update your distribution. Assuming Ubuntu still does bugfix/security updates for that version.
VLC own distributed binaries since 3.0.4 (including) should contain builds with the new library.
Have in mind, the commit in question may trigger the bug, but the commit itself may not
Re: (Score:3)
Dear AC, you are a wanker.
Even if the bug is actually due to libeml, as Kempf claims, libeml 1.3.5-2 is the current version available for Ubuntu 18.04 Bionic Beaver LTS. Updating isn't going to get you 1.3.6 or later until the Debian Multimedia Team release it to 18.04. REF: https://launchpad.net/ubuntu/+... [launchpad.net]
Re: (Score:1)
You obviously have no idea how shared libraries work on Linux based systems. You also have no idea about the fact that distro's backport security patches without updating major version numbers ... see that -2 on the end of the version/ that means its been patched... Why don't you try snagging the build source and checking the patch list before shooting your mouth off.
Re: (Score:1)
I'm not the idiot above and while I could be mistaken I don't think he was entirely wrong in this case. I see an update, but I don't see a clear security update in the Ubuntu 18.04 package:
http://changelogs.ubuntu.com/changelogs/pool/universe/libe/libebml/libebml_1.3.5-2/changelog
And Canonical does not provide security updates for packages in the universe and multiverse repositories. The "community" may, but that is just the excuse used by Canonical to only support the packages it has paying customers for.
I
Re: (Score:1)
So the correct thing to do is to report it to Debian and Ubuntu so they can update the affected library or backport the fix, rather than file a report under VLC when it wasn't actually VLC.
Problem is the researcher didn't try to track down which component was causing the crash, and never contacted to the developer to work with them before going public. The correct CVE process is to work with the developer before going public so MITRECorp dropped the ball here by ignoring that step.
Re: (Score:3)
Some distribution's package repos are a dumpster fire when it comes to moderately current packages.
This is why there is amazing confusion on these sorts of things.
You want moderately current Wine, Nvidia, or even LibreOffice? You need a distro that doesn't freeze the most stupid little things in time for years on end.
I like stable systems with packages that might be somewhat old and hopefully are compiled in a way to remove some unnecessary features that are potentially vulnerable. It is just that there i
Re: Is Kempf right? (Score:2)
Nothing else depends on... except users. I hate random breakage, paces like six months or two years are fine for feature upgrades unless I explicitly need the latest version for some reason. Now for exploits you canâ(TM)t wait six months, but most times you can backport a fix. But identifying the security related changes and supporting multiple branches is extra work, the kind of dull work people donâ(TM)t like to do. So upstream says itâ(TM)s fixed in the latest release just upgrade. Downstr
Re: (Score:2)
The alternative is to download the SNAP, which sucks because there is NO option to adjust the UI size - good luck if you can't read tiny text on your nice big monitor. Of course, if you are really really ambitious, you could try to grab the source for all the libraries a full VLC compile requires, plus VLC itself, and hope that huge poorly documented pile of code actually compiles. You
Re: (Score:2)
Will current LTS editions of Ubuntu and other popular distros actually have the most current version of VLC available in their package managers?
Yep just download the Snap. Otherwise no. Not LTS, not the normal version, no version of Ubuntu offers the current VLC version in the package manager.
It is my standard go-to case when I here neckbeards complaining about Snap as being some kind of solution looking for a problem while yelling at the kids on their lawn.
Re:Well lucky my boy turned 9 days old while readi (Score:5, Insightful)
"The guy never contacted us,"
I read the ticket and I fully realize that this vulnerability is no longer an issue (since over a year ago), but no, the guy did contact you.
He did so four weeks ago. He contacted you on the public bug tracker hosted on the videolan.org domain of your own (non-profit) of organization. I'm sorry, but if you don't read the issues flagged critical on your OWN bug tracker, then saying that he never contacted you is a pretty lousy excuse. After all, if you don't want people reporting issues on that bug tracker, then shut it down. It's not other people's fault that you give different channels to report problems. It's yours.
Kempf noted that the reporter of the supposed vulnerability did not approach VideoLAN through its reporting email address.
Of course, they didn't. I couldn't find that page myself.
A google search first led me here https://www.videolan.org/suppo... [videolan.org]
I clicked on "reporting bugs policy" and ended up here: https://wiki.videolan.org/Repo... [videolan.org]
After reading all of those procedures (which you posted by the way), I spot the word "security" at the very bottom of that page. Hooray! It looks like I found it.
https://wiki.videolan.org/Cate... [videolan.org]
Only to be disappointed.
And yes, I did double back and check your contact link.
https://www.videolan.org/conta... [videolan.org]
But obviously, that's not it either.
And obviously, you're just a non-profit and you don't have a large staff. That I understand completely. But don't blame others if you make it difficult for others to contact you about security issues.
Re: (Score:1)
The lesson to be learnt here is they don't want security flaws posted to their bug tracker, so next time they won't be.
Of course next time they also won't be sent to the non-existent security email address too.
Guess the VLC devs will have to read about it in the news just like everyone else now.
The lesson here is that if your are a serious bughunter/security researcher you check your bug on multiple distros and if you can reproduce it on multiple then you report upstream else you report to the distribution.
Re: (Score:3, Informative)
Re: (Score:3)
Not everyone thinks the same way when looking stuff up.
Also, I'm a developer, not a security researcher. That may have had something to do with it.
Re:Well lucky my boy turned 9 days old while readi (Score:4, Insightful)
If the requirement to post a security report is to GUESS a URL successfully, you have failed to practice good security.
Re: (Score:2)
It's on the site tree at the bottom of the home page. No need to guess.
stephanruby up there decided to let Google do all the work instead of his own brain and turned out looking like an idiot.
Don't fall into the same trap.
Re: (Score:2)
> for what should be obvious reasons.
There are no obvious reasons. What bugtracker can't keep security reports private by default?
If they're claiming that their bugtracker can't do this or if their bugtracker makes it difficult, or if their bugtracker has dangerous defaults, or if they're ignoring "bugspam" that are really security reports, then they need to fix their shit yesterday.
VLC has gotten a ton of EU support for security lately - lame excuses are inexcusable. So are the fake news reports (I ig
Re: (Score:2)
>There are no obvious reasons. What bugtracker can't keep security reports private by default?
The ones that don't want 2 million duplicate reports. Also the ones where all development is done in the open.
They are confused (Score:1)
I looked into it a little more and there are like 6 conflicting reports about this bug. But one major problem is that a lot of the devs/testers are misunderstanding that this bug only occurs if VLC is set to loop mode in which case the erroneous input file will memory leak until using up all memory and crash the system. In that case, yes this actually is still a bug that was duplicable even 16 hours ago. A lot of the devs aren't testing it with that in mind and you can see a lot of miscommunication happenin
Re: (Score:3)
The alleged heap-based buffer overflow flaw was disclosed by a user named "topsec(zhangwy)," who stated that a malicious .mp4 file could be leveraged by an attacker to take control of VLC media player users' devices.
There no mention of "attack" or "malicious" anywhere in that bug ticket, let alone from zhangwy. It's not mentioned in the NVD CVE either, a phrase like that possibly came from SecurityFocus or another security blogger.
Re: (Score:2)
Read on... (Score:4, Informative)
Read on on that thread. The submitter admits that it is a bug with an old version of libebml (the libebml author himself first notes this) - he cannot reproduce it after manually updating libebml and apologises.
It seems the submitter tried to contact security@ first, and only opened the bug after there was no response. The bug went unnoticed and was not responded for 4 weeks until there was suddenly all this commotion.
No idea how/why NVD picked it up with such a high score initially... Somebody jumped the gun...
Re: (Score:2)
Given your inability to provide any contribution beyond 'wrong', my guess is it's between your lips.
Re: (Score:2)
The bug was in a random third-party library that VLC dynamically links to, that was patched a year ago, and the library isn't a VLC one - the reporter in question was running old Ubuntu that happened to not include the patched version.
Many other sites did a better job of expressing this than Slashdot ever will again, it seems.
"There is no security issue in VLC" (Score:2)
My conversation with Jean-Baptiste Kempf (Score:1)