What we Can Learn from the Recent VLC Security Vulnerability Fiasco: A Conversation with VideoLAN President Jean-Baptiste Kempf
3 - 6 min read
Aug 05, 2019
About a week ago, the LinuxSecurity staff started tracking a security issue related to VLC, the popular open source media player. Security vulnerabilities are a regular part of the software development lifecycle. These vulnerabilities are identified, then a solution is created and distributed to its users. In this case, it wasn’t completely clear whether that’s what happened, though. We decided to find out.
On July 23rd, CERT-Bund published a security advisory for the popular open-source VLC media player for a vulnerability that had been fixed for the past 16 months. In the advisory, CERT-Bund warned that VLC media player version 3.0.7.1, the latest build available, contained a critical security vulnerability with a CVSS score of 9.8 out of 10. This warning indicated that the security flaw did not require privilege escalation to exploit.
It is now evident that many aspects of CERT-Bund’s advisory were incorrect. While a vulnerability did exist, it is in a third party library as opposed to in VLC itself, as security experts incorrectly indicated. It was also fixed over a year ago. The security researcher who reported the vulnerability was using Ubuntu version 18.04, which includes an older, unpatched version of the libebml library. As long as users have VLC 3.0.3 or newer installed, they are protected from the vulnerability. Once the correct information about the security bug was revealed, NIST has downgraded the vulnerability’s rating to a 5.5 (Medium).
To make matters worse, MITRE made a fundamental error in the vulnerability reporting process, publishing CERT-Bund’s report of this flaw before checking with VideoLAN. Widely accepted best practices for reporting security vulnerabilities include notifying the vendor of the bug prior to publicizing it, giving the vendor a chance to respond.
Vulnerability Reporting Best Practices
Coordinated Vulnerability Disclosure (CVD) is the process of gathering information from vulnerability finders, coordinating the sharing of that information between relevant stakeholders, and disclosing the existence of software vulnerabilities and their mitigations to various stakeholders including the public.
Here are the steps for responsible vulnerability disclosure that individuals and organizations should follow:
- As soon as you identify a security vulnerability, define the scope.
- Check if the company has:
- Identified security contacts
- A responsible disclosure web page
- A bug bounty program
- A security.txt file on their website
- Identify your country’s laws or rules defined by a bug bounty program. Document the steps you followed to discover the vulnerability and (if acceptable in your context) how to exploit it.
- Alert the company first - multiple times and people if necessary.
- Request CVE Identification.
- Alert a trusted third party like National CERT.
CERT has a great vulnerability disclosure guide that outlines a procedure for responsible disclosure an organization should follow to ensure the vulnerability is fixed prior to it being made public, to prevent the possibility of the vulnerability being exploited prior to a solution being implemented as much as possible.
In the case of the vulnerability discovered in VLC, these steps were not followed in the correct order. Had MITRE stuck to these guidelines, the widespread misconceptions surrounding this flaw would likely not have proliferated, as VideoLAN would have had a chance to correct them before they were featured in the media.
I had the privilege to speak with VideoLAN President Jean-Baptiste Kempf on Wednesday July 31st and he expressed great frustration regarding the false accusations that his company faced this past week. He commented: “This vulnerability was blown way out of proportion. Security researchers made an error in their work and propagated false information about VLC. The media fixated on this flaw, which doesn’t make sense in my opinion. Critical bugs are frequently discovered in Microsoft Windows OVP and they do not get nearly this amount of attention.”
A Strong Emphasis on Security: The History of Vulnerabilities in VLC
VLC’s security history is very good, adding to Kempf’s frustration surrounding this event. This past year, VideoLAN collaborated with HackerOne to implement a bug bounty program designed to reveal flaws in VLC. Of the thirty-one security issues that were discovered, only one was classified as critical. Security bugs are prevalent in OVPs, which can be attributed to the fast-paced development characteristic of this industry and the fact that user interaction is almost always required. All in all, VLC has a history of being more reliable and secure than other OVPs on the market, which Kempf attributes to the company’s genuine care about the quality of their products and the safety of users.
VideoLAN President Says that the Company’s Impressive Security Posture can be Partially Attributed to the Open-Source Community
The fact that VideoLAN develops and sells open-source technology may also be a factor in the company’s impressive security posture. I asked Jean-Baptiste Kempf to comment on how open-source development affects VLC’s security. He stated: “In general, I cannot go out on a limb and say that open-source development leads to superior security. There are so many factors that affect security; however, I will say that utilizing Open Source certainly won’t hurt a company’s security posture. VLC has a large community of researchers, developers and users associated with it, which we have acquired through our use of Open Source. Community involvement undoubtedly increases the security of our products, but ultimately, our values and the high standards that we hold ourselves and our products to are what allow us to achieve and maintain impressive levels of security.”
What can we Learn from this Incident?
Kempf feels that there are various lessons that can be learned from this event. People need to do their own research to minimize the risk of spreading false information, and individuals need to speak up if they feel that something in the media is incorrect. The fear factor is often abused in the infosec community, and resulting myths can have harmful and unfair effects on companies’ reputations. I hope that my writing this article will help put an end to one such myth.
Follow VideoLAN on social media for more updates:
