Cloud

3/19/2018
07:18 PM
50%
50%

AMD Processor Flaws Real, But Limited

A vulnerability report threatened falling skies over AMD processor vulnerabilities that are real but limited in impact.

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:

Interop ITX 2018

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.

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Microsoft President: Governments Must Cooperate on Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/8/2018
To Click or Not to Click: The Answer Is Easy
Kowsik Guruswamy, Chief Technology Officer at Menlo Security,  11/14/2018
Veterans Find New Roles in Enterprise Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Online Malware and Threats: A Profile of Today's Security Posture
Online Malware and Threats: A Profile of Today's Security Posture
This report offers insight on how security professionals plan to invest in cybersecurity, and how they are prioritizing their resources. Find out what your peers have planned today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19279
PUBLISHED: 2018-11-14
PRIMX ZoneCentral before 6.1.2236 on Windows sometimes leaks the plaintext of NTFS files. On non-SSD devices, this is limited to a 5-second window and file sizes less than 600 bytes. The effect on SSD devices may be greater.
CVE-2018-19280
PUBLISHED: 2018-11-14
Centreon 3.4.x has XSS via the resource name or macro expression of a poller macro.
CVE-2018-19281
PUBLISHED: 2018-11-14
Centreon 3.4.x allows SNMP trap SQL Injection.
CVE-2018-17960
PUBLISHED: 2018-11-14
CKEditor 4.x before 4.11.0 allows user-assisted XSS involving a source-mode paste.
CVE-2018-19278
PUBLISHED: 2018-11-14
Buffer overflow in DNS SRV and NAPTR lookups in Digium Asterisk 15.x before 15.6.2 and 16.x before 16.0.1 allows remote attackers to crash Asterisk via a specially crafted DNS SRV or NAPTR response, because a buffer size is supposed to match an expanded length but actually matches a compressed lengt...