AMD Processor Flaws Real, But Limited

Spectre and Meltdown qualify as two of the biggest vulnerabilities in recent years because they are flaws in the basic architecture of the most common CPU used in computing devices. Initially, customers who chose AMD processors for their servers and PCs felt vindicated in their decision, but a set of announcements have led some to question the good feelings - and others to question the questions.

There's no question that the patches applied to software in order to mitigate the Intel vulnerabilities will also have an impact on software running on AMD-centered machines. The questions arise over a set of four announced vulnerabilities unique to AMD's Ryzen and EPYC processors.

Spectre and Meltdown

Spectre and Meltdown are popular terms for a class of issues known as speculative execution side-channel vulnerabilities. Discovered by Italian academic security researchers, they take advantage of a performance-boosting feature in CPU instruction execution to see the contents of processor memory - memory that could contain unencrypted details of information like login credentials.

While AMD processors don't contain the specific vulnerabilities found in Intel processors, AMD admitted that their processors are subject to Spectre (though not to Meltdown) and a series of lawsuits asserts that AMD processors are vulnerable to similar attacks based on their architectural likeness to Intel's chips. 

AMD released a firmware patch for the EPYC and Ryzen processors after initial firmware patches from Intel were found to brick AMD CPUs if they were mistakenly applied. The AMD patches solved the bricking issue but they weren't able to work around one of the other serious problems brought on by the twin vulnerabilities; patched AMD-based systems suffered the same sort of processor slowdown that left Intel users unhappy with performance.

A Vulnerable Quartet

As the excitement over Spectre and Meltdown seemed to be settling down, a new set of vulnerabilities were announced for AMD processors. The four vulnerability categories, named Ryzenfall, Masterkey, Fallout, and Chimera by Israeli research firm CTS-Labs, would allow an attacker to inject instructions into an AMD Secure Processor and, at that point, perform a host of unpleasant things.

Almost immediately after the vulnerability announcement went public, the announcement and CTS-Labs came under fire. The criticism fell along a set of related axes: the nature of the disclosure, the nature of the exploit required, the nature of CTS-Labs, and possible unethical (or even illegal) reasons for the disclosure.

Common "responsible disclosure" practice is to alert the manufacturer (or responsible party) of a vulnerability and allow them reasonable time to either remediate the flaw or refuse remediation. Only then will the vulnerability be made public.

In CTS-Labs' case, they gave information on the vulnerabilities to AMD less than 24 hours before the public disclosure, allowing essentially no time for remediation.

CTS-Labs' CTO has published a paper defending the vulnerability release by attacking the normal behavior. Ilia Luk-Zilberman writes, "I think that a better way, would be to notify the public on day 0 that there are vulnerabilities and what is the impact. 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."

There can (and will be) significant discussion over the nature and appropriate application of ethical research guidelines, but conversation on social media and in the press seemed based on the premise that the CTS-Labs release was not the best way to begin those discussions.

Aboulnerabilities

Ryzenfall, Masterkey, and Fallout are related and tend to involve violating isolated operating modes, and being able to see into privileged memory. There are other vulnerabilities that come from these, including the ability to launch applications that are hidden and persistent. Chimera is a different set of vulnerabilities that are based around manufacturer backdoors that allow firmware re-writes to various subsystems in the computer.

It's important to note that all of the vulnerabilities detailed in this release are secondary vulnerabilities - that is, they can't be used as part of a payload to gain access to a system. Instead, they could allow dramatic escalation of an attack against an already compromised server or PC.

The nature of the vulnerabilities - that they require an already-compromised system before they can be exploited - is part of what led some professionals to criticize many aspects of the release. Linux originator Linus Torvalds was one of those levying criticism, when he wrote (as part of a Google+ discussion), "When was the last time you saw a security advisory that was basically "if you replace the BIOS or the CPU microcode with an evil version, you might have a security problem"? Yeah."

This is not to say that the vulnerabilities are not real. CTS-Labs hired well-known security company Trail of Bits to verify their research. In a blog post, Trail of Bits CEO Dan Guido wrote, "We confirmed that the proof-of-concept code worked as described on the hardware we tested..."

At the same time, Guido tempered expectations for the critical nature of the vulnerabilities, noting that exploiting them would take massive effort and that there is no immediate risk for most users. He wrote of the vulnerabilities, "They are the result of simple programming flaws, unclear security boundaries, and insufficient security testing."

One of the points of criticism regarding CTS-Labs is, essentially, that they were unknown in the security research field before these vulnerabilities were announced. Looking at the "about us" section of their website shows that the company lists itself as a a consultancy firm specializing in ASIC and embedded system security. The nature of their business makes sense in the context of the Chimera vulnerabilities, which allow for code to be injected into a part of the AMD chipset based on the Intel 8051 architecture - architecture that is taken from an embedded controller more than 30 years old.

A Possible Stock Attack

The importance of security to the computer industry has been used as another point of concern about the CTS-Labs vulnerability report. Approximately half an hour after the CTS-Labs website on the AMD vulnerabilities went live, a stock analysis firm (that also trades in stock) posted its own "Obituary" of AMD based on the CTS-Labs report.

Both Viceroy and CTS-Labs state that there is no financial relationship between the two companies and Viceroy has said that it received the CTS-Labs report from an "anonymous tipster." Nevertheless, for a company that has become infamous for shorting international stock just before writing highly critical reports, Viceroy's rapid response to the CTS-Labs disclosure strikes some as being highly suspect.

And it means...

For IT security professionals, there are two critical takeaways from the AMD vulnerability disclosure so far. The first is that there are legitimate vulnerabilities present in AMD Ryzen and EPYC processors, vulnerabilities that are part of the basic processor architecture. It is critical that security professionals be aware of these vulnerabilities, that AMD respond to them with patches and (ultimately) re-designs, and that developers work to fence the vulnerabilities away from systems in use by individuals and businesses.

The second takeaway is that the language around vulnerability research should now be scrutinized with as much care as the vulnerabilities themselves. Stock traders and others with economic, non-security interests have learned just how important security is to the modern enterprise and are ready to take advantage of that for their own gain.

Related Content:

Join Dark Reading LIVE for two cybersecurity summits at Interop ITX. Learn from the industry’s most knowledgeable IT security experts. Check out the security track here.