Scope of SGX Security Issues covered by Gramine

[ReichertL]

Hello,

I am currently working on an application for SGX using Gramine. For the security analysis I am trying to figure out which known attacks to SGX are applicable. The survey of Nilsson et al. [1] from 2020 seemed to me like a good guideline.

The survey discusses a set of attack vectors which are not stopped by Intel as they expect the developer to take care of those issues (see section IV. C). Those attacks and defenses are

• Defenses against branch shadowing attack e.g. by Lee et al. or Hosseinzadeh et al.
• Protection against interrupts from malicious OS for controlled channel attacks, such as
  • T-SGX by Shih et al.
  • Deja Vu by Chen et al.
  • Heisenberg Defense by Strackx et al.
  • SGX-LAPD by Fu et al. (for systems without TSX)
• Address space layout randomization inside the enclave (e.g. SGX Shield [2])

For most of these the authors of the respective papers developed a modified compiler which solved the problem.

I am now wondering if Gramine integrates any of these defenses? Or do developers themselves have to find a way to protect against each of these attacks? Studying published materials on the Gramine website, the mailing list and the Gramine/Graphene documentation did not make it clear to me which precautions have to be taken.

Thank you for your help.

[1] https://arxiv.org/abs/2006.13598 [2] https://github.com/jaebaek/SGX-Shield

Description of the problem

Trying to figure out the scope of SGX security issues covered by Gramine.

Expected results

Some description in the documentation about which attacks/issues are out of scope for Gramine or which additional measures one has to take so that code executed with Gramine is protected against known attacks.

Actual results

I didn't find this information anywhere, so I guess none of these attacks are covered?

[woju]

Hello and thank you for your interest in the project. If you'd like to ask a question, please write to our public mailing list at users@gramineproject.io, as described here: https://gramine.rtfd.io/#contacts-and-contributing. GitHub tracker is used for issues like bugs or feature requests. Thank you for your cooperation.

[ReichertL]

I guess it could be seen as an issue with the documentation. But I will try my luck with the mailing list. Thank you for your help.

[dimakuv]

@ReichertL As Wojtech mentioned, the mailing list would be a better option to ask such questions.

But I'll reply here, just for your convinience. Note that my explanations are not-too-formal; this is more of a personal take rather than an official stance of Gramine maintainers.

• Generally, Gramine currently does not have any defenses against side channel/controlled channel attacks. Gramine relies on the underlying hardware and firmware to thwart these attacks. E.g., recent Intel CPUs with the latest firmware updates cover a large fraction of side channel attacks.
• Gramine currently does not have defenses against so-called synchronous side-channel attacks that rely on Hyper-Threading (Intel's term for SMT). However, HT can be disabled in hardware. The status of Hyper-Threading is reported in the SGX attestation quote, so the relying party can always choose to "not trust" the remote SGX enclave that runs on an HT-enabled machine.
• Gramine does have the ASLR defense. See e.g. https://gramine.readthedocs.io/en/latest/manifest-syntax.html#disabling-aslr
• Internally, Gramine code uses the latest mbedTLS library, with the hardened and side-channel-resistant computation kernels for common crypto operations. (If you want to know the exact mbedTLS security guarantees, you need to read through mbedTLS documentation.)

Please note that Gramine does not use/require a modified compiler.

Also note that Gramine does not use any fancy (and brittle) hardware-assisted mechanisms like TSX-cloaking, etc.

Some description in the documentation about which attacks/issues are out of scope for Gramine or which additional measures one has to take so that code executed with Gramine is protected against known attacks.

Yeah, we're actually working on such a document.

[ReichertL]

Thank you @dimakuv , for this fast and detailed response.

[Villain88]

Yeah, we're actually working on such a document.

Hello, is there a draft of the document? In particular, I would like to know if the Gramin resists a frontal attack? Perhaps there are recommendations on how to reduce the likelihood of such attacks?

[mkow]

@Villain88: I have a draft, but didn't make a PR from it yet (hopefully will get to it for the next release).

In particular, I would like to know if the Gramin resists a frontal attack?

I haven't read this paper, just skimmed through the abstract, but: overall, you should assume that it will always be possible to leak control flow to some extent via side channels (the most obvious way: via unmapping code pages and monitoring page faults). So, we try to make at least Gramine's code secure against it, but it still may be a problem for the app - e.g. if it decompresses secret JPEG images via a stock decompressor, then you probably could infer some shapes on it by analyzing which code pages of decompression algorithm were executed in which order.

[Villain88]

it will always be possible to leak control flow to some extent via side channels

As I understand it, many attacks are carried out using enclave step-by-step execution, for example, using this utility. How difficult is it to attack to enclave step by step into gramine since gramine is actually one big enclave with one entry point (ecall)? Is it possible to counteract enclave single-stepping with some anti-debugging tricks from the normal world, start some kind of timer and detect that the process is slower than usual(if the enclave is not started using debugging), or such actions will only complicate the attack, but not guarantee complete protection?

[mkow]

such actions will only complicate the attack, but not guarantee complete protection?

Yes, exactly. In general, you shouldn't really base your security on control flow secrecy, only on data secrecy (e.g. use proper crypto libraries for key handling, etc.). You can try to make such attacks harder, but it's rather hard/impossible to stop them entirely, and also "hardness" is relative - an obfuscation technique you devise may actually be super trivial to circumvent, as it's often the case with hand crafted mitigations done by developers.

[Villain88]

@dimakuv, @mkow

• Gramine does have the ASLR defense.

Sorry for the intrusiveness. I'm researching sgx security issues and I am interested in vulnerabilities related with ROP (this and this for example). I tried to study the mechanism of the ASLR in gramine and did not understand whether ASLR is used to load the libpal library. Can an attacker use libpal to build gadget chains? What other parts of the gramine enclave can be used to build gadgets? I would also like to know if an attacker can intercept or predict the result of calling the PalRandomBitsRead function? Thank you for your attention to this matter.

[boryspoplawski]

I am interested in vulnerabilities related with ROP

ROP is a technique of exploitation, not a vulnerability (orthogonal thing).

Can an attacker use libpal to build gadget chains? What other parts of the gramine enclave can be used to build gadgets?

Yes. Virtually everything can be used - even the randomized addresses have low entropy. ASLR is not a strong mitigation and most of the time it can be easily broken (and I'm talking in general, not in Gramine case). This is especially true in SGX (1 and 2) case - untrusted host knows which virtual addresses have +x privileges.

I would also like to know if an attacker can intercept or predict the result of calling the PalRandomBitsRead function?

No.