Read on Twitter
About the "security issue" on #VLC : VLC is not vulnerable.
tl;dr: the issue is in a 3rd party library, called libebml, which was fixed more than 16 months ago.
VLC since version 3.0.3 has the correct version shipped, and @MITREcorp did not even check their claim.
Thread:
tl;dr: the issue is in a 3rd party library, called libebml, which was fixed more than 16 months ago.
VLC since version 3.0.3 has the correct version shipped, and @MITREcorp did not even check their claim.
Thread:
So, a reporter, opened a bug on our bugtracker, which is outside of the reporting policy, aka, mail us in private on the security alias.
Of course, our bugtracker is public.
We could not, of course reproduce the issue, and tried to contact the security researcher, in private.
Of course, our bugtracker is public.
We could not, of course reproduce the issue, and tried to contact the security researcher, in private.
The reporter is using Ubuntu 18.04, which is an old version of Ubuntu, and clearly has not all the updated libraries.
But did not answer to our questions.
But did not answer to our questions.
For whatever reason, unknown to us, @MITREcorp decided to issue a CVE, without talking to us.
This is in direct violation of their own policies, https://cve.mitre.org/cve/researcher_reservation_guidelines#researcher_reservation_guidelines#1
This is in direct violation of their own policies, https://cve.mitre.org/cve/researcher_reservation_guidelines#researcher_reservation_guidelines#1
This is not the first time that @MITREcorp does that.
In fact, they NEVER EVER contact us when they find security issues on VLC, and we always discover that after they are public, when a user or a distribution asks us.
In fact, they NEVER EVER contact us when they find security issues on VLC, and we always discover that after they are public, when a user or a distribution asks us.
When we complained, and we asked if we could manage our own CVE (like another CNA), we had no answer and @usnistgov NVD told us that they basically couldn't do anything for us, not even fixing the wrong information.
And this has been going on for years: almost all CVE on VLC have completely insane CVSS, which brings articles like the one we've seen.
Any non-exploitable read overflow get CVSS of 9.8, like VLC is a server and you could do RCE and compromised the machine, while most of the time, the issue is a crash, often not exploitable, from a local file that the user HAS to open manually.
And of course, they are never corrected.
Then, this time, for whatever reason, @certbund decided to do an advisory https://www.cert-bund.de/advisoryshort/CB-K19-0634, without checking either the crash (it's not hard), or the vulnerability, or even contacting us.
And of course, @certbund did not contact us for clarifications.
So, when @certbund decided to do their "disclosure", all the media jumped in, without checking anything nor contacting us.
and then, of course, @Gizmodo decided to play the clickbaiting of "Uninstall VLC now, or you are all going to die". Of course, @Gizmodo did not contact at all to check their info.
And then, we got hundreds of article about VLC insecurity.
And then, we got hundreds of article about VLC insecurity.
You can bet that noone of them will correct their article, or it will be in a small subtweet somewhere hidden.
@BFMTV joined of course, with the ridiculous "60%" of the fix is done, which is what the reporter added in the public bugtracker...
And to finish, both @usnistgov NVD and @MITREcorp were contacted more than 12 hours, (7pm CET) and we still are waiting for an answer, while @elpaisinenglish is asking us for clarifications...
Would @MITREcorp behave the same way if we were Microsoft or another big company?
But no, we're just a small non-profit, that does not even have the money to pay someone fulltime...
End-of-thread.
But no, we're just a small non-profit, that does not even have the money to pay someone fulltime...
End-of-thread.
