VLC Player hit by buffer overflow vulnerability in third-party library

A security researcher has warned of a serious vulnerability in VideoLAN's VLC Player (VLC), a popular media playback tool, for which no patch is yet available.

First released in February 2001 and developed under the Lesser GPL V2.1+ licence, VideoLAN Player - most commonly referred to as VLC - is one of the most popular cross-platform media playback and streaming utilities around. Sadly, that very popularity makes it a ripe target for ne'er-do-wells - making a serious flaw discovered in the latest release all the more critical.

According to the bug's entry on the Common Vulnerabilities and Exposures (CVE) project, the flaw allows malicious or otherwise badly-written code to over-read past the end of a heap-based buffer in the software's MKV demuxing function. The US National Vulnerability Database, meanwhile, rates it as a CVSS 3.0 severity of 9.8 - giving it a top Critical mark, given that it can be used to crash the system, read private data, or even access private files.

The VideoLAN bug tracker shows that the issue was first reported four weeks ago, with a description of the vulnerability and a proof-of-concept MP4 exploit which triggers a crash through heap overflow. Initial tests have indicated that the vulnerability is present in all versions up to the latest 4.0 beta, including the latest stable 3.0.7.1 release; a comment made over the weekend by one of the software's developers, however, indicates that the example exploit code 'does not crash a normal release of VLC 3.0.7.1' - which goes against the scope outlined by the NVD.

Those interested in the bug can monitor for a fix and test their own installation on the VideoLAN bug tracker.

UPDATE 20190724:

VLC has responded to the claimed security issue with a denial that its software is affected, placing the blame on an outdated third-party library shipped with selected operating systems and stating that the security researcher did not follow best practice. 'About the "security issue" on #VLC : VLC is not vulnerable,' the developers write on the official VideoLAN Twitter account. '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.

'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. 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. 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.

'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. 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.'

Those who are affected by the bug are advised to check that they are running an up-to-date copy of the libebml library, or at least a version higher than 1.3.5, rather than concerning themselves with their VLC version, which should be the case for all but selected Linux distributions whose packages were locked down more than 16 months ago. Those on Long Term Support (LTS) distributions which still ship the vulnerable library will need to manually upgrade or wait for a backport to be released by their distribution's maintainer.