Last year, we reported on a vulnerability that could allow an attacker to bypass the protections afforded by AMD’s secure encrypted virtualization (SEV) technology, found in its EPYC server processors.
When the issue came to light, AMD dismissed the exploit on the grounds that it requires physical access to the hardware, but this is only half the story. The researcher responsible for the original discovery, Robert Buhren, says physical access is only required in the first instance, after which the bug could be exploited remotely to disastrous effect.
Since then, however, another security expert by the name of Atul Payapilly has devised a workaround for the vulnerability that he says could close off the remote attack vector and preserve the utility of AMD SEV. The only problem is, AMD isn’t interested in hearing about it.
Why does it matter?
At the heart of the AMD SEV vulnerability is a mechanism known as remote attestation, whereby cloud customers can verify the correct deployment of their virtual machines.
The ability for remote attestation to function as intended hinges upon the security of the chip endorsement key (CEK), which is unique to each EPYC processor and acts as the root of trust. In the event that any AMD EYPC endorsement key is compromised by an attacker, the protections provided by AMD SEV across all deployments are rendered moot, because the keys are interchangeable.
The original researchers found that, by manipulating the voltage passing through an EPYC SoC, an error in the read-only memory (ROM) bootloader of the AMD Secure Processor (AMD-SP) could be induced, releasing the all-important CEK. This attack could be conducted on silicon purchased on the open market, meaning an attacker would not have to infiltrate hardware deployed in a production environment.
When the exploit was presented at Black Hat, Buhren claimed that there is no mitigation for the issue, which he said can only be rectified in future generations of EPYC processors.
The ramifications of this scenario are many and various. Effectively, it means that any company hoping to build services on top of AMD SEV has to halt its plans immediately and await the arrival of EYPC Genoa chips later this year - and that’s assuming a fix is delivered with the next-generation chips.
The reason Payapilly began to investigate the issue in the first place was because he found himself in precisely this position. His company, Verifiably, uses trusted execution environments to prove the integrity of code. However, now the security of AMD SEV has been called into question, the firm cannot in good faith utilize the technology to support its offering as intended.
The solution
Unconvinced by claims that there is no way to resolve the AMD SEV vulnerability that doesn’t involve waiting for new hardware to hit the market, Payapilly went in search of a solution.
The workaround he devised is built around the principle that it’s time to accept that hardware security can never be guaranteed. Therefore, we require software-based solutions capable of mitigating this risk.
The proposed solution is designed to eliminate the remote attack vector, by addressing the fact it is currently impossible to tell which chip endorsement key (CEK) has been compromised until an abuse takes place. It can be summarized as follows:
- The cloud provider populates a whitelist with CEKs extracted from each of the AMD EYPC processors it deploys
- When a customer performs remote attestation, the cloud provider cross-checks against its list of trusted keys
- The query is passed on to AMD for signature against the root key, before information is finally released
The efficacy of the workaround was confirmed separately by Buhren, although he was eager to stress that this is not a mitigation for the original attack. He also noted that the workaround would require the customer to place trust in their cloud provider.
Although nothing would be required of AMD, per se, in order for the solution to be put into practice, Payapilly says the company stands to benefit by engaging with cloud providers to implement the mitigation. However, AMD has so far shown no interest in doing so.
The company was originally contacted by Payapilly on the week of February 14, but did not return a response. On March 8, AMD told TechRadar Pro it would not comment on the opportunity for the vulnerability to be exploited remotely, the proposed workaround or plans to address the issue in future generations of EYPC processors.
Update: March 15, 07:35 ET / 11:35 GMT
An AMD representative has been in touch to contest the notion that Payapilly reported his workaround via official avenues in early February. They told us the company has no record of the initial communication.
- Also check out our lists of the best cloud storage and best web hosting providers
