Israeli security research firm CTS-Labs has published a white paper detailing nine flaws in AMD processors that they claim leave users open to devastating attacks with no mitigation strategies; these attacks include a range of manufacturer-installed backdoors.
The attacks center on AMD's secure coprocessor, a simple, separate computer that supplies security services to the main chip, including storing cryptographic keys and validating the operating system and running conditions of the main CPU, in order to fight malware attacks.
The majority of the flaws alleged by CTS-Labs attack this coprocessor. Because the main CPU derives much of its security from this system, attacks on it are largely undetectable and cannot be mitigated by installing antivirus or other security measures.
This has long been the nightmare scenario for secure computing; since the early secure computing environments were mooted with Microsoft's Palladium system, there has been a tension between applications that serve the user (like validating the operating system and ensuring it hasn't been altered by malware) and adversarial applications that treat the user as untrusted (DRM). Secure computing advocates asserted that DRM was part of the package, an inevitable side-effect of designing a computer that ran code that malware couldn't touch.
There are theoretical techniques for getting security without DRM, like owner override, in which users get to control the secure co-processor, inspecting and altering its processes. Secure computing/DRM advocates have not taken up this suggestion, insisting that we'll just have to trust manufacturers not to install malicious or buggy code in our secure co-processors. Anti-DRM advocates have countered that such a system would have terrible failure modes: code running on a co-processor that is unquestioningly trusted by the main CPU, that users can't interrogate, terminate or alter, is a juicy target for attackers. If you can get malicious code into that co-processor, then by design the rest of the system will be unable to detect or interdict it.
That's what makes the AMD attacks so scary: CTS-Labs claims that they can get malicious code to run on secure coprocessors, and that once this happens, all bets are off — and nothing users can do will help.
To drive the point home, CTS-Labs claims that some AMD processors, made by third parties, have multiple backdoors, demonstrating how untrustworthy and/or incompetent AMD is — bringing more plausibility to the idea that the company may have produced a (possibly intentionally) defective secure coprocessor.
Now, with that all said, there are some very important caveats, which are summed up well in this thread by security researcher Arrigo Triulzi and its replies.
Triulzi points out that the CTS-Labs paper is very short on technical details. Moreover, CTS-Labs' claimed defects are presented as grave in and of themselves, even though they can only be effected by attackers who are already in a position to control the user's system. For example, the MASTERKEY attack requires that the user install an untrusted BIOS update; there are many ways that such an update could allow an attacker to control the user's system, making the MASTERKEY attack somewhat redundant. The RYZENFALL attack requires that unauthorized code be loaded into the secure coprocessor; FALLOUT requires that the attacker gain control over the vendor's signing keys. Any computer that is vulnerable to these attacks is also vulnerable to much better-understood attacks and is by definition insecure, so Triulzi asserts that CTS-Labs is making a lot out of nothing.
I quibble with this: sneaking malicious code into the secure coprocessor is indeed a high barrier for attackers to hurdle — but the nature of secure computing also makes such an attack particularly grave, in a way that mere physical control and root access to a system without such a coprocessor doesn't approach. The secure copro is designed to resist inspection and alteration (to prevent attackers), and this means that defenders are effectively helpless against such an attack.
But Triulzi's other points are well-made. The CTS-Labs paper makes a bunch of irrelevant references to aerospace, the FTC, and self-driving cars that seem calculated to discredit AMD; it also includes a disclaimer that reveals that a fall in AMD share-prices could benefit CTS-Labs and/or its personnel.
CTS-Labs reportedly only gave AMD 24 hours' notice prior to publication, rather than the more common 90 days (although CTS-Labs's report is so thin on technical detail that this may not matter much).
An independent security researcher named Dan Guido was paid by CTS-Labs to review the flaws and gives some context about their significance in his Twitter timeline.
It’s important to note that all these vulnerabilities require hackers to get on the computers and gain administrative privileges some other way first, such as with a phishing attack that tricks the victim into running a malicious application, according to the CTS researchers and Guido.
This means that they are “second stage” vulnerabilities, which would allow attackers to move from computer to computer inside the same network, or install malware directly inside the processor that can’t get detected by security software. This would allow an attacker to spy on the target without detection.
“It makes a bad compromise worse,” Guido said.
(via Naked Capitalism)
