A Warning Tale on IT Security Reporting
Last week saw many media outlets - from small personal blogs to top 5 players in IT reporting - publish articles on a supposedly critical flaw in the popular VLC media player. Users were urged to go as far as to uninstall VLC immediately. Since this is an embarrassing matter that affected many otherwise reputable sources, we will refrain from linking to any specific article since any selection we could make would unfairly punish those selected over the literally hundreds of others. In this briefing, we will take a look at the bug in question, why official risk reports have to be read with some care and why you should never trust any news blindly - even if it is echoed across hundreds of sites.
Roughly four weeks ago, a bug was reported to the VLC project. Such a report is a very common occurrence, however the report indicated that the bug may allow an attacker to execute arbitrary code, thereby making it more dangerous than other bugs. The team responded to the report within a few hours, but struggled to reproduce the issue, which does happen quite often. Complex software relies on a myriad of other libraries and system services, which in turn makes some bugs extremely hard to reproduce on a different computer.
Based on this information, the team decided to investigate the bug but not rush the process. After all, a bug that cannot be reliably reproduced even by people trying to reproduce it is very unlikely to be weaponized by attackers. The risk of failure would be simply too high.
Why the panic?
Many countries have agencies that issue risk reports for newly discovered software bugs. These reports are largely automated and aim to help large enterprises and government organizations keep their IT infrastructure secure. Such reports are both read by humans, and automatically processed by software. Around two weeks ago - meaning two weeks after the initial report - several such agencies published advisories on the bug that rated it as critical. Biggest among them were the United State’s NIST and Germany’s CERT.
So surely, if these large and reputable agencies rate the bug as critical, then the reaction must have been adequate? Not so fast. The agencies rating the vulnerabilities have the goal to err on the side of safety. The reports they create are meant to be read by professionals with the ability to accurately judge the substance of the report and the potential impact on a given system. This means that bugs with no or very little available information are routinely marked as “critical”. Since no information exists, the worst case cannot be ruled out, therefore the bug is preliminarily assumed to be critical. Subsequently, experts looking at the report will notice the reasoning and lack of details and act accordingly.
Since the bug was reported to be triggered by a .mkv video file, an appropriate reaction would have been to not open unknown .mkv files until further notice. Other video files - let alone the player just being installed - presented no threat.
A panic cascade
Unfortunately, the shortage of information security talent is not limited to the primary workforce but also extends into reporting. With the demand for IT security news increasing by the day, less and less qualified writers are put in charge of writing about more and more complex topics. This seems to be exactly what happened in this case. Someone unfamiliar with the operations of NIST, CERT and others read the preliminary vulnerability report and jumped to the conclusion that the word “critical” in a report about a popular consumer-level video player was a big deal. Said writer (and those following him/her) either didn’t bother to check or didn’t have the technical skill to understand that the scope of the vulnerability was extremely limited.
Once the first couple of articles were published, other news sites and blogs jumped on the topic - feeling secure that if industry heavyweights were reporting the issue as critical then it must be true. From there the usual war for clicks started with various (mostly smaller) outlets trying to outdo one another until eventually panicked reports about an “immediate need to uninstall VLC” flooded social media and news aggregators.
According to the VLC project, the vulnerability existed not in the player itself but in an older version of a library called Matroska. The Matroska project in turn points out that the vulnerability in question has been fixed since April 2018. It appears that the person filing the bug report (who acted responsibly) may simply have had an older library installed on their system due to a lack of updates. The original media reporters (who did not - by any measure - act responsibly) either had the same old version of the library or failed to confirm the issue altogether.
Even if the issue had been current, the impact was obviously limited from the start. NIST and CERT have since updated their advisories to class the bug as “Medium” and “Low” respectively. Some users likely fell for the fearmongering and uninstalled VLC. They will need to reinstall it but no major direct harm was done.
What was harmed however was the trust in information security reporting. There are real cyber security emergencies on a regular basis, from remotely exploitable 0day vulnerabilities in operating systems to fast spreading malware like WannaCry. The public relies on IT news to keep them accurately informed about such events. Poor reporting practices like the one we witnessed last weak leads to a decrease in trust. Just like people who receive too many tornado warnings eventually stop evacuating, users receiving too many sensationalized reports on vulnerabilities eventually stop mitigating them.
As IT security news matures, this state of “yellow journalism” was an unavoidable stepping stone. The same is true for any niche that is reported on. All we can hope for now is that the yellow phase passes quickly. Otherwise, even slight decreases in user trust and compliance could lead to billions of dollars in long term losses due to increased cyber crime.