The hyperbole-laden reports of vulnerabilities in AMD-made CPUs throw up new questions surrounding the ethics of security disclosures
The much-publicized disclosure of alleged vulnerabilities in AMD’s processors was full of sound and fury, but its significance – beyond provoking a row about the ethics of security research – remains shrouded in obscurity.
Previously little-known Israeli firm CTS Labs went public last week with what it described as 13 “critical security vulnerabilities and manufacturer backdoors” in chipmaker AMD’s (latest) Ryzen and EPYC product lines.
It gave AMD, Microsoft, and a “small number of companies that could produce patches and mitigations” just 24 hours’ notice before a going live with a site dedicated to highlighting the vulnerabilities: amdflaws.com.
The website – which featured slick graphics and a amp-video of executives shot against a backdrop of CGI-generated offices – lacked either the proof of concept exploits or (worse) any information on mitigation that normally accompanies such disclosures.
The whole approach contrasts sharply with the prelude to the disclosure of the Meltdown and Spectre vulnerabilities.
Those flaws were discovered independently by security researchers from Google’s Project Zero, Cyberus Technology, and academics who worked with Intel and OS developers for around six months before going public in early January – at which point patches and other forms of mitigation were already ready.
The researchers involved in unearthing the Meltdown and Spectre vulnerabilities published proof of concept demos offering solid evidence about the impact of the information disclosure flaws they had uncovered, which were a particular threat to cloud-based systems.
Ilia Luk-Zilberman, chief technology officer at CTS Labs, followed up the initial disclosure with an open letter criticizing the established industry practice on vulnerability disclosure.
“I think that a better way, would be to notify the public on day zero that there are vulnerabilities and what is the impact,” he said.
“To notify the public and the vendor together. And not to disclose the actual technical details ever unless it’s already fixed.
“To put the full public pressure on the vendor from the get-go, but to never put customers at risk.”
‘Reckless approach’
In blog post, AMD confirmed it was assessing CTS Labs’ findings while criticizing the firm for failing to give it any time to respond to the research before going public.
The post read: “We have just received a report from a company called CTS Labs claiming there are potential security vulnerabilities related to certain of our processors.
“We are actively investigating and analyzing its findings. This company was previously unknown to AMD and we find it unusual for a security firm to publish its research to the press without providing a reasonable amount of time for the company to investigate and address its findings.
“At AMD, security is a top priority and we are continually working to ensure the safety of our users as potential new risks arise.”
Multiple security researchers and industry figures have criticized CTS Labs’ approach as reckless or worse, with some even accusing it of attempting to drive down AMD’s stock price.
CTS Labs paid US security consultancy Trail of Bits to review its research, supplying a full technical report with proof of concept (PoC) exploit code (which has not been publicly released) for each set of bugs.
“Regardless of the hype around the release, the bugs are real, accurately described in their technical report [which is not public afaik], and their exploit code works,” Dan Guido, chief executive of Trail of Bits, said in a Twitter update.
“[Amdflaws.com] is a good example of how not to disclose. Not talking about the vendor blindside, although a dick move, rather that the information CTS published is contradictory, incomplete, and convoluted,” Jericho of Attrition.org added on Twitter.
Runners and riders
CTS Labs outlined (without detail) four classes of vulnerability, all of which require pre-existing admin level access to a PC or server in order to exploit.
Hackers would first have to break into an AMD-powered PC or server and plant malware through some other vulnerability or trickery before the flaws uncovered by CTS become an issue.
None of the vulnerabilities allow malicious apps to hijack systems, unlike the SMB-based exploits that powered the spread of the infamous WannaCry ransomware last year.
A much better comparison would be with an AMD PSP (Platform Security Processor) firmware security flaw discovered by a security researcher at Google and patched in January.
The latest vulnerabilities have also drawn comparisons with BadUSB, a 2014 vintage attack that makes it possible to reprogram the firmware within some flash drives with malicious code.
The threat to an average consumer is low. In enterprise environments the vulnerabilities may create a way into the secure enclave of already compromised machines after already achieving root (admin) privileges.
Put simply, the vulnerabilities create a means for miscreants to squat on compromised systems once they’re already in.
CTS Labs admitted as much in an update, clarifying the impact of the flaws.
“The vulnerabilities described in amdflaws.com could give an attacker that has already gained initial foothold into one or more computers in the enterprise a significant advantage against IT and security teams,” it said.
“The only thing the attacker would need after the initial local compromise is local admin privileges and an affected machine.”
Masterkey – one of the vulnerabilities – would survive re-installation of the operating system but this requires BIOS re-flashing.
The other three classes of vulnerabilities require local admin privileges.
Professor Alan Woodward, a computer scientist at the University of Surrey, remains critical of CTS Labs’ approach and the tone of its report.
“I don’t dispute what they have found but I do disagree with the way they went about telling the world (and AMD),” Professor Woodward told The Daily Swig.
“I also think they overhyped it. Website, amp-video, graphics, etc, etc. I saw no PoC code either.
“As far as I can make out the vulnerability is exploitable if you are already in the device [possibly even with privileged access].”
CTS Labs did not respond to questions from The Daily Swig on why it went public with its research without offering any mitigations, workarounds, or remediation.