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
Yes Yes Maybe Maybe

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
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
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
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, 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."



View All Comments

  • HStewart - Tuesday, March 13, 2018 - link

    Well I be honest here - why would I care about non-Intel cpu's if I only used Intel CPU's but I do have QualComm 820 in my Samsung Tab S3

    One thing I believe about Internet - is that with technical information unless it coming from source of the information - I do believe I was doing messages here - before this - my primary reason is to look up technical information - but lately there has been disturbing attacks against Intel and I think it is unjustified. I know I updating here before Ryzen came out.
  • dilacerated - Tuesday, March 13, 2018 - link

    That argument is perfectly fine regarding your post history, however, if you don't have a deep level of experience with their competitors it doesn't help your case to bash those coming to their defense of something carried out in a questionable manner.

    Now full disclosure I work at a chip manufacturer (let's call them Team Blue) and the attacks are frankly justified. The level of Kool-Aid drinking inside their walls is astounding. Think Leslie Nielsen waving his hands telling everyone there's nothing to see while fire and explosions are happening behind him.

    As said the bashing of Intel for their handling of Meltdown and Spectre was fully justified. When Piednoël (who was involved in the development of some of Intel's biggest CPU architecture development, including Katmai, Conroe, Penryn, and Nehalem as well as SoCs in Sandy Bridge, Ivy Bridge, Haswell, Broadwell, Skylake, and Kaby Lake) abruptly quit in July of 2017 - - just before Ryzen and ThreadRipped launched it was odd but then we learned thats not long after Intel was informed of the vulnerabilities. Then there was the stock purge BK initiated months after the company learned of the vulnerabilities.

    That all combined with the cheap TIM fiasco that continues to this day with Intel -

    I know you think this is all new but this company has many times over done things that open them up for attack. They very frequently like to taught themselves as the most ethical entity in the tech industry yet have had many of their offices worldwide raided by countries and substantial fines leveled on them for far from ethical behavior.

    Things such as their providing software developers with a compiler that optimized code to perform better on Intel microprocessors (which hilariously made programs run slower on some of their newer CPU's) -

    Seriously read up:
  • HStewart - Tuesday, March 13, 2018 - link

    As a developer for 30 years - I would say one would used a developer that best for situation. Using Intel compiler - it is expected to run the best on their cpu. I once purchase an Intel compiler - primary because it had performance optimization before Microsoft compiler. I primary use Microsoft compilers - actually because of application I been working is quite old - it actually the Older Visual Studio 2008.

    AMD Got 1.25Million from Intel on the legal stuff - which I personally don't believe they should. I was around when originally IBM came out with PC. IBM wanted second source of CPU - thus AMD came into picture - Intel created the CPU that was in the IBM which every x86 based CPU is created from. Here is a link on original IBM PC - kind of funny - back then they thought the 8086 was too powerful - so they went with 8088

    I am old school person - been computing since 8 bit days - but technically have knowledge of detail internals of chips - I did OS work and I had personal access of all Intel CPU manuals and YES - all of AMD CPU manuals. My IBM PC came though a joint venture with neighbor on code I was developing on the side - my first actual computer that I had actually had a AMD 386 clone chip in it.
  • dilacerated - Tuesday, March 13, 2018 - link

    You're missing points again and cementing your Intel Fanboy perception by saying things like:

    "Using Intel compiler - it is expected to run the best on their cpu."

    If you even bothered to research you'd have easily read that their compiler was found to flat out look for Intel ONLY and if it didn't see what it expected it disabled extensions therefore the software it helped create crippled the performance of their competitors such as VIA/Cyrix and AMD. Worse it not only checked the vendor ID string and the instruction sets supported. It also checked for specific Intel processor models thus code generated by it failed to recognize future Intel processors with a family number different from 6.

    There's a reason tools like this exist:

    You say you are old school and bring up the IBM deal which I am old enough to remember vividly as well. You obviously then remember that Intel was required, by IBM, to find a second source and THEY chose AMD. Then in 1984, in order to shore up their advantage in the industry, Intel internally decided to no longer cooperate with AMD in supplying product information, delayed and eventually refused to convey the technical details of the 80386 to AMD despite having signed the papers and having shaked all the hands along the way.
  • HStewart - Tuesday, March 13, 2018 - link

    "Not an Intel Fanboy? Registered late 2017 and have posted exclusively in Intel articles:

    Something is wrong about this this query - I just included an actually question on recent Xbox One Freesync with questions about my monitors and up and coming update from Microsoft and this query did not find it - conclusion this is some how only searching for Intel related comments in last couple of months.
  • dilacerated - Tuesday, March 13, 2018 - link

    Uh, what?

    That's looking for results with

    Google may not have cached the results for that article that was published just yesterday...
  • dilacerated - Tuesday, March 13, 2018 - link

    Anyhow my point in general having run several or nearly all offerings for Desktop/Mobile/Server CPU's from the likes of Intel, VIA, Cyrix, SPARC, DEC, AMD, Qualcomm, Samsung, Apple, MediaTek, Transmeta and so on is that not all of them are their 100% competitors equal. You got to play with them to fully see where they benefit you and where they have room for improvement.

    BUT only one of those companies has a HUGE track record of shady business tactics to gain an advantage in their space AND has been legally convicted of doing so:

    As a result many of their competitors have vanished in the meantime because, as Andre Agassi once said, "image is everything" and Intel has done a VERY good job of damaging the images of many of their competitors.

    Even recently they tried to smear AMD for "glueing" ThreadRipper and EPYC CPU's together while omitting that they ever did so -
  • mode_13h - Tuesday, March 13, 2018 - link

    It doesn't take a genius to write asm. I've worked with enough to say that from experience.

    Also, doesn't mean you're not a troll or a shill. Everything about this reveal is shady. If you can't see that, there's no hope for you.
  • dilacerated - Tuesday, March 13, 2018 - link

    Meltdown and Spectre were not attempts to smear Intel and it is perplexing that you even think this.

    Both were VERY well documented and because of the gravity of them Intel and others involved (including AMD!) were given the 180 day + period to sort out a solution unlike the news today.
  • Manch - Wednesday, March 14, 2018 - link

    liar Reply

Log in

Don't have an account? Sign up now