Security Researchers Publish Ryzen Flaws, Gave AMD 24 hours Prior Noticeby Ian Cutress on March 13, 2018 12:25 PM EST
Through the advent of Meltdown and Spectre, there is a heightened element of nervousness around potential security flaws in modern high-performance processors, especially those that deal with the core and critical components of company business and international infrastructure. Today, CTS-Labs, a security company based in Israel, has published a whitepaper identifying four classes of potential vulnerabilities of the Ryzen, EPYC, Ryzen Pro, and Ryzen Mobile processor lines. AMD is in the process of responding to the claims, but was only given 24 hours of notice rather than the typical 90 days for standard vulnerability disclosure. No official reason was given for the shortened time.
As of 3/13 at 5:40pm ET, AMD has since opened a section on its website to respond to these issues. At present, the statement says:
"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. We will update this blog as news develops."
At this point AMD has not confirmed any of the issues brought forth in the CTS-Labs whitepaper, so we cannot confirm in the findings are accurate. It has been brought to our attention that some press were pre-briefed on the issue, perhaps before AMD was notified, and that the website that CTS-Labs has setup for the issue was registered on February 22nd, several weeks ago. Given the level of graphics on the site, it does look like a planned ‘announcement’ has been in the works for a little while, seemingly with little regard for AMD’s response on the issue. This is compared to Meltdown and Spectre, which was shared among the affected companies several months before a planned public disclosure. CTS-Labs has also hired a PR firm to deal with incoming requests for information, which is also an interesting avenue to the story, as this is normally not the route these security companies take. CTS-Labs is a security focused research firm, but does not disclose its customers or research leading to this disclosure. CTS-Labs was started in 2017, and this is their first public report.
CTS-Labs’ claims revolve around AMD’s Secure Processor and Promontory Chipset, and fall into four main categories, which CTS-Labs has named for maximum effect. Each category has sub-sections within.
MasterKey 1, 2, and 3
MasterKey is an exploit that allows for arbitrary code execution within the secure processor of the CPU, but requires the attacker to re-flash the BIOS with an update that attacks the Arm Cortex A5 at the heart of the secure processor. In one version of MasterKey, the BIOS update uses metadata to exploit the vulnerability, but the goal is to bypass AMD’s Hardware Validated Boot (HVM). The impact of MasterKey would allow security features to be disabled, such as the Firmware Trusted Platform Module or Secure Encrypted Virtualization. This could lead to hardware-based random attacks. CTS-Labs cite that American Megatrends, a common BIOS provider for Ryzen systems, makes a BIOS re-flash very easy, assuming the attacker has a compatible BIOS.
|Impact||EPYC||Ryzen||Ryzen Pro||Ryzen Mobile|
|MasterKey-1||Disable Security Features
AMD Secure Processor
CTS-Labs state that MasterKey-1 and Masterkey-2 has been successfully exploited on EPYC and Ryzen, but only theorized on Ryzen Pro and Ryzen Mobile by examining the code. Masterkey-3 has not been attempted. Protection comes via preventing unauthorized BIOS updates, although if Ryzenfall compromised system may bypass this.
Chimera HW and Chimera SW
The Chimera exploit focuses on the Promontory chipset, and hidden manufacturer backdoors that allow for remote code execution. CTS-Labs cites that ASMedia, the company behind the chipset, has been fallen foul of the FTC due to security vulnerabilities in its hardware.
|Chimera HW||Chipset code execution||No||Yes||Yes||No|
A successful exploit allows malicious code that can attack any device attached through the chipset, such as SATA, USB, PCIe, and networking. This would allow for loggers, or memory protection bypasses, to be put in place. It is cited that malware could also be installed and abuse the Direct Memory Access (DMA) engine of the chipset, leading to an operating system attack. CTS-Labs has said that they have successfully exploited Chimera on Ryzen and Ryzen Pro, by using malware running on a local machine with elevated administrator privileges and a digitally signed driver. It was stated that a successful firmware attack would be ‘notoriously difficult to detect or remove’.
Ryzenfall 1, 2, 3, and 4
The Ryzenfall exploit revolves around AMD Secure OS, the operating system for the secure processor. As the secure processor is an Arm Cortex A5, it leverages ARM TrustZone, and is typically responsible for most of the security on the chip, including passwords and cryptography.
|Ryzenfall-1||VTL-1 Memory Write||No||Yes||Yes||Yes|
|Ryzenfall-2||Disable SMM Protection||No||Yes||Yes||No|
|Ryzenfall-3||VTL-1 Memory Read
SMM Memory Read (req R-2)
|Ryzenfall-4||Code Execution on SP||No||Yes||Maybe||No|
CTS-Labs states that the Ryzenfall exploit allows the attacker to access protected memory regions that are typically sealed off from hardware, such as the Windows Isolated User Mode and Isolated Kernel Mode, the Secure Management RAM, and AMD Secure Processor Fenced DRAM. A successful attack, via elevated admin priveledges and a vendor supplied driver, are stated to allow protected memory reads and writes, disabling of secure memory protection, or arbitrary code execution.
Fallout 1, 2, and 3
Fallout applies to EPYC processors only, and is similar to Ryzenfall. In fact, the way that CTS-Labs describes the vulnerability, the results are identical to Ryzenfall, but relies on compromising the Boot Loader in the secure processor. Again, this is another attack that requires elevated administrator access and goes through a signed driver, and like Ryzenfall allows access to protected memory regions.
|Fallout-1||VTL-1 Memory Write||Yes||No||No||No|
|Fallout-2||Disable SMM Protection||Yes||No||No||No|
|Fallout-3||VTL-1 Memory Read
SMM Memory Read (req F-2)
CTS-Labs states this as a separate name on the basis that it can bypass Microsoft Virtualization-based security, open up the BIOS to flashing, and allow malware to be injected into protected memory that is outside the scope of most security solutions.
What Happens Now
As this news went live, we got in contact with AMD, who told us have an internal team working on the claims of CTS-Labs. The general feeling is that they have been somewhat blindsided by all of this, given the limited time from notice to disclosure, and are using the internal team to validate the claims made. CTS-Labs state that it has shared the specific methods it used to identify and exploit the processors with AMD, as well as sharing the details with select security companies and the US regulators.
All of the exploits require elevated administrator access, with MasterKey going as far as a BIOS reflash on top of that. CTS-Labs goes on the offensive however, stating that it ‘raises concerning questions regarding security practices, auditing, and quality controls at AMD’, as well as saying that the ‘vulnerabilities amount to complete disregard of fundamental security principles’. This is very strong wording indeed, and one might have expected that they might have waited for an official response. The other angle is that given Spectre/Meltdown, the '1-day' disclosure was designed for the maximum impact. Just enough time to develop a website, anyway.
CTS-Labs is very forthright with its statement, having seemingly pre-briefed some press at the same time it was notifying AMD, and directs questions to its PR firm. The full whitepaper can be seen here, at safefirmware.com, a website registered on 6/9 with no home page and seemingly no link to CTS-Labs. Something doesn't quite add up here.
AMD have us on speed-dial for when an official statement is released.
Sources: AMD, CTS-Labs
Update 3/13 5:40pm ET
Reported over at Motherboard are a few new elements to the story.
Dan Guido, founder of security firm Trail of Bits, was contacted by CTS Labs last week to confirm the exploits and the code.
"Each of them works as described,",
Stated Guido. Guido has confirmed to AnandTech that Trail of Bits has had no prior contact with CTS-Labs, stating that
"they found us through a mutual friend".
Guido goes on to say that CTS-Labs
"sought us out because they were concerned about the validity of their findings".
In a tweet, Guido goes on to say that Trail of Bits was paid for their research time, clarifying further that
"It was driven by curiosity first and a favor. However, once we received the technical report and fielded their first set of questions, we realized it went beyond a favor. We anticipated 1 bug, not 13, so we asked to get paid."
Reuters has published that Trail of Bits were paid $16000 for the time spent reviewing the code.
Motherboard also stated that due to the escalated privileged required for these attacks, these are 'second stage' vulnerabilities, requiring the attacker to gain administrative access first before installing relevant (potentially undetectable) spying software on a network.
Also reported at Motherboard, CTS-Labs CEO, Ido Li On, has stated that the issues are
"very, very bad. This is probably as bad as it gets in the world of security,"
CTS-Labs decided to state to Motherboard when they notified AMD of the issue, but CFO Yaron Luk-Zilberman defended their timing decisions, calling it a "public interest disclosure". Luk-Zilberman is also quoted as saying
"We are letting the public know of these flaws but we are not putting out technical details and have no intention of putting out technical details, ever"
CTS-Labs has reached out to discuss the issue, but have not responded to my email.
Update 3/14 4:45am ET
We have arranged a call with CTS-Labs today.
Update 3/14 5:00am ET
Reported by Ars Technica, a second security firm has now spoken publicly about being contacted by CTS-Labs for verification of the vulnerabilities. Gadi Evron, CEO of Cymmetria, stated in a series of tweets that:
- He knows CTS-Labs and vouches for their technical capabilities, but has no knowledge of their business model
- All the vulnerabilites do not require physical access (a simple exe is all that is needed)
- Fallout does not require a reflash of the BIOS
- CTS-Labs believes that the public has a right to know if a vendor they are using makes them vulnerable, which is why no substantial lead time was given.
Quoted by Ars is David Kanter, founder of Real World Technologies and industry consultant, who verifies that even though these are secondary stage attacks, they can still be highly important. David states that while
"All the exploits require root access - if someone already has root access to your system, you're already compromised. This is like if someone broke into your home and they got to install video cameras to spy on you".
Ars also quotes Dan Guido, who states that all that is needed to enable these exploits is the credentials of a single administrator:
"Once you have administrative rights, exploiting the bugs is unforunately not that complicated."