Intel-SA-00219 mitigations

[burdges]

There are suggestions for Intel-SA-00219 mitigations at https://github.com/apache/incubator-teaclave-sgx-sdk/wiki/Mitigation-of-Intel-SA-00219-in-Rust-SGX but they make no sense:

How would a u64 on only one side of secret data help, except by imposing 8 byte alignment? I'd think#[repr(align(8))] for types like Scalar suffices, except.. How does 8 byte alignment help if a cache line is 64 bytes?

It treats the stack attackable, but an enclave appears trivially exploitable if it shares stack with outside code. I think some rowhammer-like attacks perform writes with numerous reads, so afaik an enclave cannot even permit outside code read access.

Any thoughts? @tarcieri ?

[tarcieri]

Don't know offhand, sorry

[isislovecruft]

Hi @burdges, thanks for bringing this up! So, my reading of the bug is: if you are running some code which handles secrets in an SGX enclave on a CPU which has an integrated GPU, the GPU can always read the first two DWORDs (8 bytes in total) from a cache line, therefore their solution is to pad datatypes which hold secrets with 8 bytes before the secret data occurs (combined with 8-byte alignment, so as to enforce that the guard bytes completely overlap the first two DWORDs).

[isislovecruft]

Also to answer some of the questions over on w3f/schnorrkel#52:

Would #[repr(align(8))] alone suffice?

From my understanding, I don't believe so. It sounds like the first two DWORDs in a cache line are always accessible and thus need to be padded with garbage. Obviously, this is really bad news, as it means that secrets are now 40 bytes.

If so, that's way simpler. Should we ask curve25519-dalek for #[repr(align(8))] on Scalar?

I'm not sure how others feel, but I suspect that the mitigation (particularly the padding!) would be rather expensive to do for all Scalars, especially given that there are many contexts (e.g. randomisation factors, etc.) in which a Scalar may not be a secret. Rather, it seems more appropriate to apply the mitigation in higher level primitive constructions. (Feel free to disagree and try to convince me otherwise?)

[tomtau]

The official advisory is brief and @dingelish's article tries to deduce more from Intel SDK and PSW's code changes, so it's unclear how one should proceed around patching cryptographic libraries. In intel/linux-sgx@d166ff0 Intel didn't seem to have patched, for example, openssl, so it may be fine to leave this mitigation for higher level primitive constructions.

It'd be useful if someone from @IntelSTORMteam (@rrbranco @barbieauglend @vpxorq @KekaiHu @honorarybot @pinkflawd @wildsator) could comment on this.

[hdevalence]

From looking at Intel's vulnerability description, it seems like the problem is with SGX, and that it is not fixable in application code. There are no intra-enclave security boundaries in SGX -- the entire enclave memory is supposed to be secret -- so it doesn't seem meaningful to say "this enclave data is extra secret, so we'll keep it away from the front of the cache line". I have extreme doubts that the suggested mitigations would be effective, or that it's appropriate to put them in this library.

[tomtau]

There are no intra-enclave security boundaries in SGX -- the entire enclave memory is supposed to be secret.

That's a bit strong statement. At this stage, it's unclear how exactly Intel-SA-00219 can be exploited (I couldn't find PoC code -- if someone has it, please share it) -- it could just be on boundaries/interleaving in combination with outside memory (+ integrated gpu), as other similar quirky footguns exist, such as this one, and enclave application developers need to wrap their heads around them, unfortunately.

I agree that it may not be appropriate to put mitigations in this library (i.e. do it for all Scalars) -- it may be better to leave them as optional in higher-level applications.

[WildCryptoFox]

The compiler could remove any padding. The stack may contain temporaries. The general problem is hard and is not solved by zeroize et al; even with pinned memory. The compiler must be involved for in-depth mitigations.

[burdges]

If I understand, Intel has not released enough information for any meaningful mitigation. A priori, we should expect entire cache lines to ultimately be attackable, not just the first 8 bytes. In particular, an attacker can tweak the cache line alignment before the enclave even creates its secrets so that any padding lands in another cache line.

As an aside, I'm kinda okay with SGX being vulnerable on consumer machines with integrated GPUs. As a rule, ethical SGX use cases consist of servers doing attestations for clients, or simply protecting node operators from their own key material without attestation, while attestations by end user machines turn out unethical, ala DRM. Any ethical end users use cases might survive with address space randomization.

[rrbranco]

While our team did find the issue, we do not coordinate fixes (or take care of the public advisories), which are centralized by Intel PSIRT. I do recommend reaching out to them with the questions and the need for guidance (overall it helps us as well, since we keep pushing for more openness overall). Best regards, Rodrigo (BSDaemon).

…

On Mon, Dec 16, 2019, 23:52 Jeff Burdges ***@***.***> wrote: If I understand, Intel has not released enough information for any meaningful mitigation. A priori, we should expect entire cache lines to ultimately be attackable, not just the first 8 bytes. In particular, an attacker can tweak the cache line alignment before the enclave even creates its secrets so that any padding lands in another cache line. As an aside, I'm kinda okay with SGX being vulnerable on consumer machines with integrated GPUs. As a rule, ethical SGX use cases consist of servers doing attestations for clients, or simply protecting node operators from their own key material without attestation, while attestations by end user machines turn out unethical, ala DRM. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#310?email_source=notifications&email_token=AAEVFAO3BIELQUGLJYDP7ILQZCAMRA5CNFSM4J3QZJQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHBPQRQ#issuecomment-566425670>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEVFAJAWQPW6DI323HRVKLQZCAMRANCNFSM4J3QZJQQ> .

[Demi-Marie]

My understanding of this issue:

1. The stack is indeed vulnerable. The problem is with the silicon, so it does not matter whether a particular piece of memory is heap or stack.
2. Therefore, compilers will need to avoid using stack addresses such that (addr & 0x40) < 8. I am not sure if this is practical. If it is not, this means that secrets can only safely be accessed by hand-written assembly.
3. 8 byte alignment is not enough. For security, contiguous secret regions of memory must be cache-line (64 byte) aligned, begin with 8 bytes of padding, and be no longer than 56 bytes. Larger secrets will need to be split into smaller ones.

[hdevalence]

It seems that what Intel is really saying is that SGX enclaves cannot store any data in the first 8 bytes of every 64-byte cache line, which is clearly not a problem that this library (or really any other application code) can solve. So I am going to close this issue as being out of scope.

[Demi-Marie]

@hdevalence Do you mean that it is the compiler’s responsibility, or that SGX and Intel integrated graphics are simply incompatible?

[oleganza]

@demimarie-parity fwiw, SGX has other fatal deficiencies.

[hdevalence]

@demimarie-parity I'm not sure whose responsibility it would be -- for instance, whether it's possible for a compiler to ensure that enclaves never store data in the first 8 of every 64 bytes -- but it's not something that this library can fix. My suspicion is that this problem is not fixable, because most programs require more than 56 bytes of contiguous memory at a time.

[Demi-Marie]

@oleganza what are they? @hdevalence it could be fixed by some form of emulation (basically, compile to a VM that does not use those bytes), but that would be very clumsy and slow.

[tomtau]

For reference: questions and replies from Intel PSIRT:

1a. What is a more detailed scope of Intel-SA-00219? How can attacks using an integrated GPU be launched? Is there a PoC code?

a. Intel does not provide information how to exploit product vulnerabilities as a matter of company policy.

1b. Could an attacker access DWORD0 and DWORD1 of cache line at arbitrary execution points, or is it limited (e.g. before or after specific instructions, such as ERESUME or EENTER)?

b. An attacker can access affected data in DWORD0 and DWORD1 at anytime in the enclave life cycle.

2a. Most enclave applications will use standard cryptographic libraries, such as openssl, and these libraries may do intermediate computations with secret values that will not use the new SDK memory allocation APIs from the developer guidance document. Should the external cryptographic libraries that enclave application use be patched as well?

a. Application developers need to assess the risk of the attack and the applicability of the mitigation technique in the standard cryptographic libraries for their application. Some libraries actively clean their own intermediate values as soon as they are done with them, which can significantly increase the difficulty of an adversary reading that data.

2b. Even with the new SDK memory allocation APIs, it may not be sufficient, as there are not many guarantees: compilers may reorder data (and parts of secret values may end up in affected memory locations), optimize away paddings etc. Does Intel plan more robust mitigations?

a. There are no plans for more robust software mitigations at this point in time. Intel recommends application developers and system users follow the mitigation guidance outlined in the Security Advisory. (INTEL-SA-00219 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00219.html )

[tomtau]

TLDR: in hindsight, it's not much different from the previous hyperthreading-related vulnerabilities. My take on it is this:

1. if your enclave application is isolated / local-only (TPM-like use cases): SGX enclaves make sense only if the end user can trust the hardware configuration they are executed on (disabled hyperthreading, no or disabled integrated gpu, ...).
2. if your enclave application does remote attestation, IAS / DCAP should be reporting the integrated gpu state (as it did with hyperthreading):

An attestation response may report a “CONFIGURATION_NEEDED” for platforms that have applied the microcode update and SGX platform software where the integrated processor graphics technology remains enabled. The Remote Attestation Verifier should evaluate the potential risk of an attack on these platforms.