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
within
AMD Secure Processor
Yes Yes Maybe Maybe
MasterKey-2
MasterKey-3

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.

  Impact EPYC Ryzen Ryzen
Pro
Ryzen
Mobile
Chimera HW Chipset code execution No Yes Yes No
Chimera SW

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.

  Impact EPYC Ryzen Ryzen
Pro
Ryzen
Mobile
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)
No Yes Yes No
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.

  Impact EPYC Ryzen Ryzen
Pro
Ryzen
Mobile
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)
Yes No No No

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:

  1. He knows CTS-Labs and vouches for their technical capabilities, but has no knowledge of their business model
  2. All the vulnerabilites do not require physical access (a simple exe is all that is needed)
  3. Fallout does not require a reflash of the BIOS
  4. 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."

Comments Locked

211 Comments

View All Comments

  • Yojimbo - Thursday, March 15, 2018 - link

    "But all that aside, there's no possible way that you can claim that in this particular case, the 90 days was irrelevant. It's very clearly irresponsible disclosure in this specific case. The facts are very clear!"

    I don't think the facts are so clear. There is a possible way we can claim the time is irrelevant if we were actual security experts who understood the situation. Are you in the security community?

    I wonder how much security research is done with a mind towards telling companies about vulnerabilities compared to the amount that is done with a mind towards not telling companies about them.
  • Manch - Wednesday, March 14, 2018 - link

    " I don't see it that way. I don't see why a company should be protected for 90 days. The only reason I can think of for the 90 days is to prevent security breaches."

    I honestly don't understand why you're arguing. The 90 days is not to protect the company. It's as you just said, to prevent security breaches. It gives the company a chance to patch before it becomes known in the wild. THIS protects consumers as well as the companies bottom line. It's beneficial to both parties. Granted, no technical how to was released. What they did and what has people upset is they said If you want to breach AMD's procs, this is the path you need to go. If this is in fact legitimate, people that are working to breach these procs and do not have the best intentions either now know to change their attack vector or it confirms they're on the right path. It is very careless and dangerous to release this to the media FIRST and then to AMD after the fact. This endangers anyone with that hardware.

    TBS, at face value the prerequisites to even exploit this is dubious at best. It is very questionable in how they went about announcing it. The website and everything else about the company seems odd.

    Who did it and why? For what reason? Something is up. I don't believe Intel or NVidia is stupid enough to try something like this. Somebody is up to something. This story will unravel and get more interesting.

    I'll neither defend Intel blindly like H Stewart, or attack them and accuse them like a lot of people here are. This is not the Luminati with Intel Inside planning an evil take down. Something is up though.
  • Yojimbo - Wednesday, March 14, 2018 - link

    "The 90 days is not to protect the company. It's as you just said, to prevent security breaches. It gives the company a chance to patch before it becomes known in the wild."

    I am asking when that is appropriate and when that isn't. I don't understand why you think its strange I should ask such a question. I think I made the reason I brought it up clear. It's because there is a strong attitude that AMD "deserves" the x days, and that CTS labs did something "dirty" by not giving AMD 90 days. Now you can insist that the reason for the x days is to protect the customers, but if the attitude becomes occified that companies deserve this time that could be a dangerous thing. So I am asking: rather than giving 90 days, did CTS labs actually increase the risk to the public by letting them know of these vulnerabilities immediately, without publishing the technical information, or have they reduced the risk to the public? I don't believe anyone has a clear answer to that because they haven't really considered it. If one considers it and decides that the x days system is the most secure, there still is the issue that the attitude is that a company "deserves" this treatment.

    Again, the "who did it and why" conspiracy theories of this particular case are not relevant to the issue I am raising. There may or may not be some sort of manipulation going on here. But that is not the issue I am concerned with. Now, one could argue that immediate release of information makes it easier to try to manipulate the stock price. That is something to consider, but I'm not convinced that that in itself is enough of a reason to choose the other route. Any specific instance of potential securities fraud would be a case for the SEC, or whatever equivalent entity in any other country, to investigate.
  • Manch - Thursday, March 15, 2018 - link

    I think its strange bc you answered your own question. I don't think AMD deserves protection anymore than Intel. The customers on the are the ones that need protecting. ALL processors have flaws. If you don't give them the chance to know about it, they cant fix it. If you don't give them a time frame, they'll never get it done. So you got to find a balance between giving them a chance to fix it and protecting the consumers by not providing a roadmap for hackers or god forbid, laying out exactly how to do it.

    As far as CTS goes, they are in cahoots with Viceroy research which is trying to manipulate AMD stock. yes, I think that by releasing this to the press before notifying AMD and then bashing AMD for not having a fix to an unkown prob reaks to high heaven. It puts users at considerable risk even without giving technical details because you have given the vector to which AMD procs should be attack. AMD will now be scrambling to test/validate/patch trying to beat the hackers. This will result in a rushed patch/solution that could be just as bad or ineffective. It serves no one but CTS to release this the way they did. Add in their collusion with Viceroy and it becomes even more egregious. But, like you I wont speculate into the motives or accuse AMD's competitors but it's fair to acknowledge that it stinks.

    CTS Labs in conjunction with viceroy research DID do something dirty. They def didn't do it for the good of the people.
  • Manch - Thursday, March 15, 2018 - link

    Also, I find strange that they claim they were researching ASMEDIA for a year and never said anything to anybody. ASMEDIA is not exclusively AMD and its strange other security researchers haven't found ANYTHING.
  • Yojimbo - Friday, March 16, 2018 - link

    "Also, I find strange that they claim they were researching ASMEDIA for a year and never said anything to anybody. ASMEDIA is not exclusively AMD and its strange other security researchers haven't found ANYTHING."

    Yeah, you definitely don't. You have a one track mind...
  • Yojimbo - Friday, March 16, 2018 - link

    "I think its strange bc you answered your own question."

    I don't think you understand the issue I am raising.
  • danjw - Wednesday, March 14, 2018 - link

    They pre-briefed media and hired an outside firm to verify it, before they told AMD. This is a red flag.

    If they were concerned about consumers, they would have made sure AMD knew before letting anyone outside their group knew. That way AMD could try to address the issues before crackers figured out how to exploit these vulnerabilities. Now the crackers know where to look for these vulnerabilities and AMD has had very little time to even investigate if they are valid.
  • Yojimbo - Thursday, March 15, 2018 - link

    "If they were concerned about consumers, they would have made sure AMD knew before letting anyone outside their group knew. That way AMD could try to address the issues before crackers figured out how to exploit these vulnerabilities. Now the crackers know where to look for these vulnerabilities and AMD has had very little time to even investigate if they are valid."

    Is it reasonable to expect that people can find, implement, and distribute the vulnerabilities before AMD can fix them?

    Correct me if I am wrong, but if I remember there was a case some time ago (was it the zero days exploits?) where companies knew about vulnerabilities and did nothing about them. The public was not alerted. Then the vulnerabilities, along with the technical details, were leaked. In such a case the public really are hung out to dry. Or suppose someone finds vulnerabilities, informs the company, and the company doesn't do anything. What then? The finder releases all information to the public? Is that fair to the customers?

    I don't know the answers to these questions, but I feel that people are having a knee jerk reaction here without really considering the situation. Frankly, if someone were to be incentivized to find security vulnerabilities it might be better if they sell the information to financial investors, for which the existence of the vulnerabilities need to be revealed, rather than those who wish to use the vulnerabilities. I dunno. I'm guessing no one has a good idea of how much that goes on, except possibly for the entities that buy the most vulnerabilities.
  • ಬುಲ್ವಿಂಕಲ್ ಜೆ ಮೂಸ್ - Wednesday, March 14, 2018 - link

    Check out Dan Goodins article on this over at Ars Technica

Log in

Don't have an account? Sign up now