Subject: Processors | March 20, 2018 - 04:33 PM | Ryan Shrout
Tagged: ryzenfall, masterkey, fallout, cts labs, chimera, amd
AMD’s CTO Mark Papermaster released a blog today that both acknowledges the security vulnerabilities first shown by a CTS Labs report last week, while also laying the foundation for the mitigations to be released. Though the company had already acknowledged the report, and at least one other independent security company validated the claims, we had yet to hear from AMD officially on the potential impact and what fixes might be possible for these concerns.
In the write up, Papermaster is clear to call out the short period of time AMD was given with this information, quoting “less than 24 hours” from the time it was notified to the time the story was public on news outlets and blogs across the world. It is important to detail for some that may not follow the security landscape clearly that this has no relation to the Spectre and Meltdown issues that are affecting the industry and what CTS did find has nothing to do with the Zen architecture itself. Instead, the problem revolves around the embedded security protocol processor; while an important distinction moving forward, from a practical view to customers this is one and the same.
AMD states that it has “rapidly completed its assessment and is in the process of developing and staging the deployment of mitigations.” Rapidly is an understatement – going from blindsided to an organized response is a delicate process and AMD has proven its level of sincerity with the priority it placed on this.
Papermaster goes on to mention that all these exploits require administrative access to the computer being infected, a key differentiator from the Spectre/Meltdown vulnerabilities. The post points out that “any attacker gaining unauthorized administrative access would have a wide range of attacks at their disposal well beyond the exploits identified in this research.” I think AMD does an excellent job threading the needle in this post balancing the seriousness of these vulnerabilities with the overzealous hype that was created upon their initial release and the accompanying financial bullshit that followed.
AMD provides an easy to understand table with a breakdown of the vulnerabilities, the potential impact of the security risk, and what the company sees as its mitigation capability. Both sets that affect the secure processor in the Ryzen and EPYC designs are addressable with a firmware update for the secure unit itself, distributed through a standard BIOS update. For the Promontory chipset issue, AMD is utilizing a combination of a BIOS update and further work with ASMedia to further enhance the security updates.
That is the end of the update from AMD at this point. In my view, the company is doing a satisfactory job addressing the problems in what must be an insanely accelerated time table. I do wish AMD was willing to offer more specific time tables for the distribution of those security patches, and how long we should expect to wait to see them in the form of BIOS updates for consumer and enterprise customers. For now, we’ll monitor the situation and look for other input from AMD, CTS, or secondary security firms to see if the risks laid out ever materialize.
For what could have been a disastrous week for AMD, it has pivoted to provide a controlled, well-executed plan. Despite the hype and hysteria that might have started with stock-shorting and buzzwords, the plight of the AMD processor family looks stable.
Much Ado About Nothing?
We live in a world seemingly fueled by explosive headlines. This morning we were welcomed with a proclamation that AMD has 13 newly discovered security flaws in their latest Ryzen/Zen chips that could potentially be showstoppers for the architecture, and AMD’s hopes that it can regain lost marketshare in mobile, desktop, and enterprise markets. CTS-Labs released a report along with a website and videos explaining what these vulnerabilities are and how they can affect AMD and its processors.
This is all of course very scary. It was not all that long ago that we found out about the Spectre/Meltdown threats that seemingly are more dangerous to Intel than to its competitor. Spectre/Meltdown can be exploited by code that will compromise a machine without having elevated privileges. Parts of Spectre/Meltdown were fixed by firmware updates and OS changes which had either no effect on the machine in terms of performance, or incurred upwards of 20% to 30% performance hits in certain workloads requiring heavy I/O usage. Intel is planning a hardware fix for these vulnerabilities later on this year with new products. Current products have firmware updates available to them and Microsoft has already implemented a fix in software. Older CPUs and platforms (back to at least 4th Generation Core) have fixes, but they were rolled out a bit slower. So the fear of a new exploit that is located on the latest AMD processors is something that causes fear in users, CTOs, and investors alike.
CTS-Labs have detailed four major vulnerabilities and have named them as well as have provided fun little symbols for each; Ryzenfall, Fallout, Masterkey, and Chimera. The first three affect the CPU directly. Unlike Spectre/Meltdown, these vulnerabilities require elevated administrative privileges to be run. These are secondary exploits that require either physical access to the machine or logging on with enhanced admin privileges. Chimera affects the chipset designed by ASMedia. It is installed via a signed driver. In a secured system where the attacker has no administrative access, these exploits are no threat. If a system has been previously compromised or physically accessed (eg. force a firmware update via USB and flashback functionality), then these vulnerabilities are there to be taken advantage of.
In every CPU it makes AMD utilizes a “Secure Processor”. This is simply a licensed ARM Cortex A5 that runs the internal secure OS/firmware. The same cores that comprise ARM’s “TrustZone” security product. In theory someone could compromise a server, install these exploits, and then remove the primary exploit so that on the surface it looks like the machine is operating as usual. The attackers will still have low level access to the machine in question, but it will be much harder to root them out.