Reminiscent (but unrelated to) the Spectre and Meltdown vulnerabilities that plagued Nvidia earlier this year, AMD was recently hit with a fairly significant set of vulnerabilities. Although the vulnerabilities were less severe than the ones hitting Nvidia (these vulnerabilities require administrative access to exploit rather than just the ability to write memory), the method by which they were made public is alarming.
According to AMD’s initial assessment, there are three groups of vulnerabilities, all requiring administrative access to exploit. MASTERKEY is an exploit by which someone who has already corrupted the system can hide their corruption from the AMD Secure Processor checks throughout reboot. RYZENFALL and FALLOUT allow a user to install malware on the system that is difficult to detect. While those issues will be patched with a firmware update, CHIMERA is a hardware issue that allows malware to be hidden, which cannot be fully patched through an update.
According to AMD as well as various media outlets, the company had less than 24 hours after being notified of the issues before the discoverer (CTS Labs) went public with the vulnerabilities. While the technical details of the vulnerability were not (and have still not yet been) made public, this creates very bad PR for AMD, as well as encourages others who may have access to the technical details to exploit the issue before a fix can be made (compared to only knowing that they had been discovered as a fix was released).
In response to the controversy, Ilia Luk-Zilberman (the Chief Technology Officer of CTS Labs) posted an open letter explaining the decision as well as their issues with responsible disclosure. Responsible disclosure is a generally-agreed-upon policy that, upon finding a serious security issue with a program, software, or system, one should report it to the manufacturer, maintainer, or security team so that they can have a patch ready before the public knows of the issue. This helps maintain PR, prevent a company from being caught off-guard, and helps consumers know that they are as protected as they can be. This policy was handled with many recent exploits such as DirtyCOW and Spectre/Meltdown (although those were accidentally leaked a few days early).
Another aspect of responsible disclosure is a time limit on the vulnerability (typically cited as 90 days) before the discoverer posts the vulnerability. This is to ensure that the company puts priority on fixing the issue instead of pushing it off (after all… even though it’s broken, no one knows about it, so it’s probably fine). This famously happened with the MoonPig vulnerability last year, in which the greeting card company MoonPig had an incredibly broken API (there was no need to log in as a user, just cite their user ID), and refused to fix it for over a year until the details went public.
CTS Labs, however, decided that the risk of not going public outweighed the benefits, so they released the possible impacts of the vulnerabilities without disclosing technical details of the vulnerability or how to exploit it.
– Ryan V.