Security Week 31: VLC vulnerability and broken phone

Last week ( news ) a serious vulnerability was widely discussed in the popular VLC media player. Information about the problem was added to the registry of the German CERT Bund threat response center and to the US National Vulnerability Database . Initially, the CVE-2019-13615 vulnerability received a rating of 9.8, that is, it was classified as the most dangerous.

The problem is due to a read error beyond the boundaries of the buffer in the heap that may occur when playing a video. If explained in more human terms, you can send the prepared .mkv file to the victim and gain control of the system through the execution of arbitrary code. This news is a good reason to talk about problems in the software, which, it seems, does not pose serious risks for your computer. But not this time: apparently, the researcher who reported the vulnerability made a mistake and attributed the latest version of VLC to a problem that existed exclusively in his Linux distribution. Therefore, today's post is dedicated to misunderstanding and sensational headlines.

It all started five weeks ago with this ticket in the VLC bug tracker. The user topsec (zhangwy) without further description uploaded the .mp4 file, which causes the player to crash. There, this message lay without attention for a while, while information about the vulnerability somehow (no one knows which one) got into the NIST NVD and CERT Bund databases. After that, the developers looked at the bug report - and could not reproduce the attack on the latest version of the media player.


Meanwhile, the media wrote about the vulnerability with a link to the CERT Bund, and no one was embarrassed with the headlines there . Remove VLC Now! A terrible vulnerability for which there is no patch! Everything is very bad ! In general, large organizations that maintain a registry of vulnerabilities in software are usually trusted. But in this case, the normal process of detecting a problem and finding a solution for it was disrupted.
')

What exactly went wrong, VideoLan developers said in a series of tweets in the official account (we recommend reading the whole thread , the developers were very angry and did not embarrass themselves in expressions). To begin with, VLC urgently asks researchers not to report vulnerabilities to the public tracker. For obvious reasons: if a really serious problem is discovered, developers should have time to fix it. The original topsec user bug report got into the public part of the tracker.


Secondly, the initiator of the bugreport did not get in touch when they tried to clarify details with him. Thirdly, NIST NVD base maintainers added vulnerability information and assigned a near-maximum hazard rating without consulting the VLC developers. The CERT Bund did the same, after which the media picked up the topic.

Was there a vulnerability? It was! In the libebml library, which is part of the open source project Matroska.org . VLC does access this library when parsing MKV files, but vulnerabilities used in the exploit were closed in version 1.3.6 in April 2018. Starting with version 3.0.3, VLC itself uses an updated library. It took a very rare combination of the relatively old and apparently not updatable Ubuntu system with the old libebml library and the new player to implement the attack. It is clear that such a configuration is unlikely for ordinary users, and VLC has nothing to do with it anyway - for more than a year now.


The last message from the author of the original bugreport looks like this: "You are sorry, if that." But the real vulnerability with similar properties was closed in the actual version VLC 3.0.7 at the date of publication of the digest. It was also contained in the open library used by VLC, and led to the execution of arbitrary code when opening the prepared file. It was discovered thanks to the initiative of the European Union to reward vulnerabilities in popular (and used by government agencies) open source projects. In addition to VLC, Notepad ++, Putty and FileZilla were included in the list of software.

In general, security is more about a process than a result. The quality of this process is determined not by high-profile headlines in the media, but, in the case of your personal computer, by at least regular software updates. Problems can be anywhere, and the fact that the VLC vulnerability turned out to be fake does not eliminate the need to constantly update programs. Even those that seem to work and are not perceived as dangerous. These include, for example, the WinRAR archiver, in which a very ancient critical vulnerability was found a few months ago. Disabling VLC update reminders is also not worth it, although many do. A relatively recent Avast study in January of this year showed that only 6% of users had the current version of VLC installed at that time.


VLC developers, in principle, do not like the practice when any vulnerabilities with arbitrary code execution are assigned the maximum danger rating. In most cases, the actual operation of such a hole is difficult: it is necessary for the victim to send the necessary file (or a link to the streaming video), and force it to open, and cause not just the crash of the program, but execution of the code, and even with the necessary privileges, which are not the fact that available. This is an interesting theoretical version of a targeted attack, but so far unlikely.

Disclaimer: The opinions expressed in this digest may not coincide with the official position of Kaspersky Lab. Dear editors generally recommend treating any opinions with healthy skepticism.