Dodgy vids can hijack PCs via VLC security flaw, US, Germany warn. Software's makers not app-y with that claim

Updated VLC is said to be once again vulnerable to remote-code execution – meaning a booby-trapped video opened by the software could potentially crash the media player, or joyride it to run malware on the host machine.

However, the developers of the open-source application, which has been downloaded literally billions of times and used by countless netizens, have disputed this claim, and say it is not possible to exploit the programming blunder.

The US government's NIST this month documented a "critical" heap-based buffer over-read, designated CVE-2019-13615, which is said to be present and unpatched in the most recent official version of VLC, 3.0.7.1. The flaw is, we're told, present in the Linux, Unix, and Windows builds of the player.

According to NIST:

While Germany's CERT and NIST have both logged the flaw in their databases as dangerous and exploitable, the developers of VLC are pumping the brakes on panic over the vulnerability.

For one thing, it appears to be an out-of-bounds read, so it may be impossible to leverage into remote code execution.

In a bug-tracking ticket discussing CVE-2019-13615, VideoLAN lead developer Jean-Baptiste Kempf also noted that he was unable to recreate a crash using a proof-of-concept .MP4 video, provided by a security researcher four weeks ago, that's supposed to knacker the latest version of VLC, 3.0.7.1. Nor was he able to crash the older 3.0.6 and work-in-progress releases, such as 3.0.8, he reported.

"This does not crash a normal release of VLC 3.0.7.1," added Kempf. "Sorry, but this bug is not reproducible and does not crash VLC at all."

VLC developer Francois Cartegnie was more blunt earlier today: "If you land on this ticket through a news article claiming a critical flaw in VLC, I suggest you to read the above comment first and reconsider your (fake) news sources."

When The Register tried playing the proof-of-concept .MP4 in VLC version 3.0.7 Vetinari (3.0.7-0-g86cee31099) on Linux, the player crashed with a segmentation fault. So there is confusion over what Kempf meant by "does not crash" – because it surely does crash – and whether by "the bug is not reproducible," he meant remote-code execution is impossible or possible.

It appears the crashy .MP4 was generated as a result of an automated bug-hunting fuzzer running against VLC. El Reg has asked VLC developers at VideoLan for additional comment on the matter, and will update the story when we hear back.

Whether the flaw can be confirmed or not, the clash should serve as a reminder to users and admins that media plugins and players such as VLC can and do contain security vulnerabilities, and should regularly be updated to thwart attempts by hackers to exploit bugs within the code.

Earlier this year, veteran Apple security researcher Patrick Wardle explained how VLC and other legacy applications could be used by attackers as entry points for attackers looking to get around newer macOS security protections. In that scenario the software itself is not vulnerable, but rather has privileges associated with it that could allow a malicious plugin to get at sensitive system components. The media player's maker also just recently patched a bunch of flaws in VLC by releasing version 3.0.7.1. ®

Updated to add

VLC's developers maintain they are not at fault, their software is not vulnerable, and there's nothing to fix: use the latest version of the media player with its latest libraries, and you should be fine. The problem lies within libebml, which has been fixed since version 1.3.6, which was released more than a year ago.

Copies of VLC packaged by Linux distros using an out-of-date libebml will therefore encounter a crash, at least, with the proof-of-concept .MP4 video.

So in short: remote code execution is unlikely, and a crash is possible, but only if you're using an out of date libebml with VLC. Use the latest versions of these pieces of software, and you'll be all right.

Now there's an argument raging over whose fault all of this is: the government agencies issuing alerts without double checking the severity; the libebml maintainers for not getting a CVE identifier and flagging up version 1.3.6 as a security fix, hence why Linux distributions did not pick up the update; or VLC for not keeping a handle on the state of its third-party libraries?

NIST and Germany's CERT have since downgraded their advisories.