Foreshadow And Intel SGX Software Attestation: The Whole Trust Model Collapses

Interview In the wake of yet another collection of Intel bugs, The Register had the chance to speak to Foreshadow co-discoverer and University of Adelaide and Data61 researcher Dr Yuval Yarom about its impact.

The main promise of SGX is that you can write code, and ship it to someone you do not fully trust. That person will run the code inside SGX on their machine, and you can see [it]…

Dr Yarom explained that one of the big impacts of Foreshadow is that it destroys an important trust model – SGX attestations, which guarantee that the code you publish is the code someone else is running.

Think of it as tamper-evident packaging for software: having published your software, the SGX remote attestation will fail if someone changes it. If things are working properly, you only know a remote machine has signed the software – not whose machine it was.

If a Foreshadow (CVE-2018-3615) exploit were successful, it could break both the attestation and the privacy model.

Dr Yarom told us: “The main promise of SGX is that you can write code, and ship it to someone you do not fully trust. That person will run the code inside SGX on their machine, and you can see that whatever they run there is protected, because you know… they haven’t modified your code, they haven’t accessed the data that your code used.”

Someone writing a video player, he said, could use this as a rights protection mechanism: the player doesn’t allow copying, and the publisher knows it’s behaving correctly, because they’re receiving the signed SGX attestation saying so.

“As part of our attack, what we managed to do is get the attestation keys.

“We can take your code, analyse it to see what it does, know how it should behave, change that behaviour – but we can fake the attestation,” he said – the code they run as attackers doesn’t match the publisher’s code, but the “tampered” code passes all the validity checks.

In the video player example, the attacker can change the code so it creates a copy of content, but still “allow it to attest to vendor of the software that it is still running, protected.”

“The whole trust model collapses,” Dr Yarom told us.

In a press release from CSIRO/Data61, Dr Yarom said: “Intel will need to revoke the encryption keys used for authentication in millions of computers worldwide to mitigate the impact of Foreshadow.”

As we observed reporting the vulnerability exploited by Foreshadow (and the other two vulnerabilities* that Intel discovered while investigating fixes), Intel created the exposure by prioritising performance over security, and Dr Yarom agreed.

“It’s clear that Intel’s recent design decisions focussed on how to optimise processors … so that typical programs execute faster.

“What we now see is that these optimisations, particularly when we don’t understand them, come at the cost of information about what the program is doing.”

He added that such decision-making isn’t confined to Intel.

Dr Yarom said Intel’s black-box approach to processors is the reason Data61 is putting its weight behind the RISC Foundation’s open hardware efforts.

“It’s about getting to know what’s inside a processor, and getting to be able to make a guarantee of the behaviour of the processor.

“We need to make sure that these sorts of attacks aren’t feasible, and for that we need the ability to reason about the behaviour of the processor,” he said.

We need to make sure that these sorts of attacks aren’t feasible, and for that we need the ability to reason about the behaviour of the processor

Dr Yarom was part of one of two teams who independently discovered Foreshadow, working with Marina Minkin and Mark Silberstein of Technion; Ofir Weisse, Daniel Genkin, Baris Kasikci, and Thomas Wenisch of the University of Michigan.

A team from the imec-DistriNet research group at the KU Leuven – Jo Van Bulck, Frank Piessens, and Raoul Strackx – made the same discovery independently.

Dr Yarom explained that after Meltdown and Spectre landed in January, it was clear to researchers that SGX was a logical next vector to attack.

“Marina [Minkin] had worked with SGX, we talked about it a bit, and she mentioned a scenario which in SGX caused an access violation exception, instead of falling into ‘abort page semantics’. Because Meltdown is related to access violation exceptions we decided to give it a try.”

Once you know where to look for a vulnerability, he said, “most of the hard part is done”. ®

* The researchers have called two related vulns – CVE-2018-3620 and CVE-2018-3646 – “Foreshadow-NG” (next generation). Intel refers to the three flaws collectively as “L1 terminal fault“.

Yarom and the rest of the team are presenting “Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution” on 16 August at the Usenix Security conference.

Sponsored: Following Bottomline’s journey to the Hybrid Cloud

READ MORE HERE