As a security company running a vulnerability database, our primary responsibility is to provide accurate information about vulnerabilities in various software and issue factual and neutral advisories. However, in this quest of ours we can encounter various difficulties, especially from vendors who are overprotective about their code and in denial about the vulnerabilities found in their software. They misinterpret our advisories as a misrepresentation of facts in order to make them look bad.
A recent legal threat was from VLC, regarding Secunia Advisory SA51464, which was issued for a use-after-free vulnerability in VLC. The vulnerability was publicly reported by a third party researcher Kaveh Ghaemmaghami on the Full-Disclosure mailing list in VLC version 2.0.4. The root cause of the vulnerability lies in the underlying FFmpeg library, which VLC statically links to. It was reported that the vulnerability was caused due to a buffer overflow issue when parsing SWF files, which was incorrect. Secunia Research performed additional research on the reported issue and correctly analysed it to be a use-after-free issue. When the VLC security team became aware of this vulnerability, they tried to fix the issue. However, they failed to understand the root cause and provided a patch which did not fix the core issue.
When the VLC team released version 2.0.5, which claimed to fix SA51464, Secunia Research contacted the VLC security team and informed them about the incorrect patch. However, VLC apparently disregarded our mail.
Later, another researcher independently contacted us via SVCRP (Secunia Vulnerability Coordination Reward Program) and reported a vulnerability in VLC version 2.0.5. When we analysed the vulnerability, it turned out to be the same use-after-free issue described in SA51464 – only the vector this time was via an AVI file rather than an SWF file. After completing our analysis we decided to contact the VLC team again with the new PoC in an effort to inform them about the core problem. Unexpectedly, the VLC team again disregarded the issue and claimed that the vulnerability was fixed. We found the response concerning, especially since two completely unrelated researchers had found the same vulnerability, which increases the chances of a malicious person exploiting this issue. We decided to give the VLC team time, expecting that they would re-visit the issue and provide a proper fix.
However, even after VLC version 2.0.6 had been released we noticed that the core problem remained unpatched. Various changes done in other parts of the code did make exploitation difficult, but the issue was still unpatched. On May 21st, 2013, the VLC team contacted us after office hours and threatened us with legal action if we did not update Secunia Advisory SA51464 and changed its patch status within 24 hours of sending the email. In the same email they also claimed that we were lying to our customers about the unpatched vulnerability. This was surprising, since we had repeatedly contacted the VLC team and tried to keep an open communication with them, as getting the vulnerability fixed would benefit the users of both VLC and Secunia.
The next day we re-visited the issue, however, we came up with the same result, that the use-after-free vulnerability did indeed exist in version 2.0.6. Crafting an exploit, as mentioned earlier, was a bit tricky, due to changes in other parts of the code. Exploitation required inducing and winning a small race condition between the release and use of memory. However, since we could not prove exploitation, we decided to change the status to “Patched”. We decided to give VLC the benefit of the doubt, until we had done additional research and had a better proof of exploitability.
We conducted further analysis after we updated our advisory and concluded that the issue is exploitable even in the newly released version 2.0.7. We have therefore updated our advisory and set the patch status of Secunia Advisory SA51464 to unpatched. Any future legal action from the VLC team will be dealt with accordingly.
While the curious case of the use-after-free vulnerability was going on, we received a new coordination report for a vulnerability in VLC version 2.0.6. The vulnerability is an integer overflow error when parsing MKV (Matroska) files. Exploiting the vulnerability is surprisingly straight forward and we reported the vulnerability to the VLC team on April 23rd, 2013. The VLC team acknowledged receiving the vulnerability report and stated that they would need more time to fix the vulnerability. As per our disclosure policy, the vendor was contacted after one month of the initial disclosure date as a part of our monthly status update cycle to get an update on the status of the fix. As a response, we expected the vendor to provide us with a timeline or a date on which a patch for the vulnerability would be released. However, the vendor responded stating that he didn’t know what vulnerability we where referring to, and that Secunia wasn’t collaborating with VLC, so why should they help us. VLC must clearly have misunderstood something here, as it is Secunia that is helping VLC by coordinating a vulnerability with them and even providing them with a reliable PoC. We tried to make this clear in our response to them, hoping that they would understand the issue. However, they replied that the issue is only a crash, which results in the application gracefully terminating. This was despite the fact that the vendor was provided with a PoC, which could reliably control the contents of the corrupted memory. We informed the VLC team that, as per our disclosure policy, if a vendor does not provide us with timely updates or is unwilling to fix the issue, then we would release our advisory to make the users aware of the risk so that they may protect themselves via other means e.g. not opening untrusted files or using other software until a patch for the vulnerability is available.
We’re not sure if our communication wasn’t clear enough, since VLC publicly claimed that we were threatening them about vulnerabilities. At no point did we digress from our disclosure policy, or threaten the vendor in any way, and were merely looking out for the safety of the users of VLC. The vendor further went on to state that they would block the installation of VLC if they detected an installation of Secunia’s PSI, unless we would stop our lies. We consider this a confirmation that the vendor is unwilling to coordinate the vulnerability with Secunia and therefore we have decided to publish our advisory for the integer overflow error for the safety of the VLC user base. In order to be sure and not to leave a blind spot, we even tested the then nightly releases of VLC and noticed that while the issue was fixed in the nightly released of version 2.1.0, the nightly release of version 2.0.7 was affected. The latest stable version 2.0.7 is still affected by the issue and our advisory states this.
A lot can be said about these episodes and VLC. That VLC apparently doesn’t think vulnerabilities in third party libraries, for example FFmpeg (which is statically linked), are issues they would need to warn their users about, but only vulnerabilities in the “main” VLC code, is obviously not the right thing to do, and gives a false image on the security status of VLC.
Although we generally discourage having communication with vendors through blog posts and alike, sadly we see no way forward in coordinating vulnerabilities with VLC. Until we receive a reach out from VLC and see a noticeable change in attitude and behaviour, we will drop all kind of cooperation with VLC, and publish all future vulnerabilities found immediately.