10 ms·

How SGX Fails in Practice

158 points by gbrown_ 6y ago

pstrateman 6y ago
So this breaks SGX completely. Signals new PIN thing relies (almost) entirely on SGX being secure to make their encrypted profile and contact backups secure. This attack reduces the security of the Signal encrypted backups to just the PIN. Edit: Indeed the authors point this out explicitly in the SGAxe paper.
- usmannk 6y ago
  > Signals new PIN thing relies (almost) entirely on SGX being secure to make their encrypted profile and contact backups secure. This just seems irresponsible. How could they excuse this? It seems like anyone who has even peripherally been working with TEEs recently is _well_ aware that SGX is broken beyond repair. It's not just a matter of patching bugs, this whole model seems bunk.
  - RL_Quine 6y ago
    Seems unlikely they were mentioned in the paper in this depth without being made even casually aware that this paper would be published. Which means they just went ahead with it anyway.
  - lima 6y ago
    Still useful for plausible deniability if the government comes knocking.
  - saagarjha 6y ago
    Even people not working on TEEs are aware that SGX is broken. Actually, you don't even have to even know what SGX is to bring up the concern that their entire scheme relies on SGX working correctly.
- anonymousDan 6y ago
  Nah. If it can be fixed with a microcode update it's not the end of the world.
  - lxgr 6y ago
    Definitely not the end of the world, but the utility of a trusted computing implementation depends a lot on the track record of actually being one, and SGX's isn't exactly great.
    - uluyol 6y ago
      To be honest, you could say the same about SSL/TLS, browsers, and (probably) virtualization. Secure enclaves are new. It takes time to develop new technologies and work out all the issues. I probably wouldn't trust my data to SGX today, but I'm not opposed to it as an idea. In 5-10 years it may be in a reasonable state.
      - yjftsjthsd-h 6y ago
        If we had a heartbleed every month, then I'd be rethinking whether I want to trust anything to TLS, yes. Browsers are awful, and tolerable only because they provide so much value (and even then, I overwhelmingly only run a browser with extra mitigations in place). And no, virtualization probably shouldn't be trusted against hostile code.
        pjmlp 6y ago
        As long as we rely on languages like C for our foundations, we will have them, just not always on TLS, that is why it is so relevant to push for better foundations, even when most of us aren't doing systems programming.
  - rcxdude 6y ago
    If you're relying on it for remote attestation (which is what signal is doing) it's not any use for that, because you have no real verification that the microcode has been updated.
usmannk 6y ago
At this point SGX is just so broken that it seems like its only purpose is to provide PhD students something to write a paper on :) I'm hesitantly excited for AMD's SEV enclave to roll out. Anyone know if it's shaping up to be any better?
- ENOTTY 6y ago
  SEV has been subjected to its own share of attacks (and design/implementation fails), but note that it has a different threat model. * https://arxiv.org/pdf/1712.05090.pdf https://arxiv.org/pdf/1712.05090.pdf 2017 * https://arxiv.org/pdf/1612.01119.pdf https://arxiv.org/pdf/1612.01119.pdf 2017 * https://arxiv.org/pdf/1805.09604.pdf https://arxiv.org/pdf/1805.09604.pdf 2018 * https://ipads.se.sjtu.edu.cn/_media/publications/fidelius_hpca18.pdf https://ipads.se.sjtu.edu.cn/_media/publications/fidelius_hp... 2018 * https://seclists.org/fulldisclosure/2019/Jun/46 https://seclists.org/fulldisclosure/2019/Jun/46 2019 * https://www3.cs.stonybrook.edu/~mikepo/papers/severest.asiaccs19.pdf https://www3.cs.stonybrook.edu/~mikepo/papers/severest.asiac... 2019 * https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf 2019 * https://arxiv.org/pdf/1908.11680.pdf https://arxiv.org/pdf/1908.11680.pdf 2019 * https://arxiv.org/pdf/2004.11071.pdf https://arxiv.org/pdf/2004.11071.pdf 2020 Any enclave technology will be reliant on the underlying security of the processor itself. Someone was going to have to go first. Intel happened to take greater risks in the name of performance, and all of their technologies (including their first-to-market enclave technology) are suffering reputational hits as a result. I'll also just mention that CrossTalk is the more interesting vulnerability affecting SGX that was disclosed today.
  - usmannk 6y ago
    Oh huh, I see. Thanks for the papers. "Someone was going to have to go first. Intel happened to take greater risks in the name of performance, and all of their technologies (including their first-to-market enclave technology) are suffering reputational hits as a result." Very true, and a point worth making. Just curious, do you work closely with SGX/SEV? You were quick with the links!
- anonymousDan 6y ago
akersten 6y ago
Remember, SGX is not a security feature. It is a DRM feature meant to take control away from the owner of the machine and give it to content owners. Happy to see every successful attack against this module, and hoping that Intel decides to just ditch it entirely.
- lxgr 6y ago
  Oh boy, here we go again. No, SGX is a technology allowing for the trusted execution of code in an untrusted environment. DRM is one potential application of that technology. See also the comment section on literally _every other HN submission with SGX in the title_, for example here: https://news.ycombinator.com/item?id=22495251 https://news.ycombinator.com/item?id=22495251
  - akersten 6y ago
    Yes, indeed here we go again, because I fundamentally disagree that "allowing the trusted execution of code" is any different than DRM. A rose by any other name. I believe a user should have full control over the hardware they own. SGX and other enclaves are a direct affront to that, and I won't give up the fight. If you need a "trusted execution" of code, run it on a server you control.
    - _jal 6y ago
      > If you need a "trusted execution" of code, run it on a server you control. What CPU do you use for this purpose?
      - akersten 6y ago
        I understand the implication here to be "how can you trust your own hardware anyway," and the answer is "of course in theory you can't." Even if you had SGX and wrote your algorithm or whatever to run in it, if your hardware's compromised, the horse has left the stable. Your proprietary algorithm and input that you developed on the compromised hardware are already available to the attacker. So having SGX locally is not going to help. At the end of the day, SGX is not going to defend a proprietary computation if the input and algorithm are already compromised.
mmm_grayons 6y ago
Boy, I'd love to see Moxie's comment on this after years of shilling SGX. I was always disappointed by that and never understood why someone as otherwise-bright as him went for it.
- anonymousDan 6y ago
  There have been several attacks like this already (and more likely more to come). The nice thing about the SGX design is many of these issues can be fixed immediately with a microcode update. Now if an attack is announced that can't be fixed with a microcode update that is another story :). In general, protecting against these kinds of attacks for any enclave is a hard problem, but it is an active area of research and there are already research proposals for more side channel resilient enclave designs (e.g. see the Keystone project from Berkeley). I expect some of these mitigations will be incorporated into future iterations of SGX, but it will take time.
  - mmm_grayons 6y ago
    You're right, and the idea of a secure enclave is not an inherently bad one. What is bad is treating it as an unassailable fortress, as in signal's address book feature. There's a difference between using it to make critical parts of existing computations more secure and using it to do stuff one wouldn't otherwise do.
    - dane-pgp 6y ago
      > You're right, and the idea of a secure enclave is not an inherently bad one. Maybe it is when you're trusting private keys and proprietary technology controlled by a single entity that may be subject to commercial and political pressures that make their motives not aligned to yours.
      - anonymousDan 6y ago
        I hope you're not typing that on an Intel processor :)
makomk 6y ago
This is one of two lovely side-channel vulnerabilities in Intel processors released today. Apparently they also leak RDRAND and RDSEED data across cores and took 18 months to fix it: https://www.vusec.net/projects/crosstalk/ https://www.vusec.net/projects/crosstalk/
- Dunedan 6y ago
  > The mitigation locks the entire memory bus before updating the staging buffer and only unlocks it after clearing its content. Entire memory bus as in entire access to any kind of shared memory (shared CPU caches, RAM, ...)? If yes, wow, that's a pretty desperate mitigation. Doesn't that starve large parts of the whole CPU whenever an affected, but mitigated instruction is executed, as all other cores can't interact with memory anymore for the duration of this execution? Doesn't that also open the ability to "DoS" CPUs by constantly executing such instructions?
  - 0x0 6y ago
    Hmm, now I wonder if this could turn into a F00F-like bug? What would LOCK REP RDRAND or just REP CPUID do...
    - strstr 6y ago
      You can still acknowledge interrupts in between, so hardware watchdogs will prevent this.
  - the8472 6y ago
    You can already do that with split locks, which also lock the memory bus.
    - rigtorp 6y ago
      Yeah, split locks have a huge performance impact, especially with high core counts: https://rigtorp.se/split-locks/ https://rigtorp.se/split-locks/ Fortunately the Linux kernel can kill offenders with SIGBUS: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Split-Locks-Detection https://www.phoronix.com/scan.php?page=news_item&px=Linux-Sp...
deleted 6y ago
[deleted]
exabrial 6y ago
> Our bot provides Attestation as a Service (AaaS) slow clap
deleted 6y ago
[deleted]
jiveturkey 6y ago
Fixed in January. https://blogs.intel.com/technology/2020/06/ipas-security-advisories-for-june-2020/ https://blogs.intel.com/technology/2020/06/ipas-security-adv... > Finally, in January 2020 we released INTEL-SA-00329 addressing two side-channel issues. Specifically, CVE-2020-0549 addressing an issue called “L1D Eviction Sampling” which has been referred to by researchers as “CacheOut”. The CacheOut researchers recently informed us of a new paper referred to as SGAxe. It is important to note that SGAxe relies on CVE-2020-0549 which has been mitigated in microcode (confirmed by the researchers in their updated CacheOut paper) and distributed out to the ecosystem. And from the CacheOut paper: > Finally, Intel had indicated that microcode updates mitigating the root cause behind CacheOut will be published on June 9th, 2020. We recommend these be installed on all affected Intel platforms to properly mitigate CacheOut. The above blog is indeed dated june 9, however it indicates that the fix was made available, and verified, back in January. I find fault, or at minimum a conflict, between the researchers publication as of june 9, and Intel's statement on the same date. Pretty horrible. I especially dislike that the paper has a section called "Current Status", while the paper is undated as is the norm for academic papers of this type. The "Current Status" isn't 100% clear but appears to be current as of November 2019, so yes this would be in advance of both the June 9 supposed date and the apparent January actual date. Perhaps the paper linked on the sgxaxe website isn't the "updated CacheOut paper" that Intel refers to.

158 points by gbrown_ 6y ago

So this breaks SGX completely. Signals new PIN thing relies (almost) entirely on SGX being secure to make their encrypted profile and contact backups secure. This attack reduces the security of the Signal encrypted backups to just the PIN. Edit: Indeed the authors point this out explicitly in the SGAxe paper.

usmannk 6y ago
> Signals new PIN thing relies (almost) entirely on SGX being secure to make their encrypted profile and contact backups secure. This just seems irresponsible. How could they excuse this? It seems like anyone who has even peripherally been working with TEEs recently is _well_ aware that SGX is broken beyond repair. It's not just a matter of patching bugs, this whole model seems bunk.
- RL_Quine 6y ago
  Seems unlikely they were mentioned in the paper in this depth without being made even casually aware that this paper would be published. Which means they just went ahead with it anyway.
- lima 6y ago
  Still useful for plausible deniability if the government comes knocking.
- saagarjha 6y ago
  Even people not working on TEEs are aware that SGX is broken. Actually, you don't even have to even know what SGX is to bring up the concern that their entire scheme relies on SGX working correctly.
anonymousDan 6y ago
Nah. If it can be fixed with a microcode update it's not the end of the world.
- lxgr 6y ago
  Definitely not the end of the world, but the utility of a trusted computing implementation depends a lot on the track record of actually being one, and SGX's isn't exactly great.
  - uluyol 6y ago
    To be honest, you could say the same about SSL/TLS, browsers, and (probably) virtualization. Secure enclaves are new. It takes time to develop new technologies and work out all the issues. I probably wouldn't trust my data to SGX today, but I'm not opposed to it as an idea. In 5-10 years it may be in a reasonable state.
    - yjftsjthsd-h 6y ago
      If we had a heartbleed every month, then I'd be rethinking whether I want to trust anything to TLS, yes. Browsers are awful, and tolerable only because they provide so much value (and even then, I overwhelmingly only run a browser with extra mitigations in place). And no, virtualization probably shouldn't be trusted against hostile code.
      - pjmlp 6y ago
        As long as we rely on languages like C for our foundations, we will have them, just not always on TLS, that is why it is so relevant to push for better foundations, even when most of us aren't doing systems programming.
- rcxdude 6y ago
  If you're relying on it for remote attestation (which is what signal is doing) it's not any use for that, because you have no real verification that the microcode has been updated.

usmannk 6y ago

At this point SGX is just so broken that it seems like its only purpose is to provide PhD students something to write a paper on :) I'm hesitantly excited for AMD's SEV enclave to roll out. Anyone know if it's shaping up to be any better?

ENOTTY 6y ago
SEV has been subjected to its own share of attacks (and design/implementation fails), but note that it has a different threat model. * https://arxiv.org/pdf/1712.05090.pdf https://arxiv.org/pdf/1712.05090.pdf 2017 * https://arxiv.org/pdf/1612.01119.pdf https://arxiv.org/pdf/1612.01119.pdf 2017 * https://arxiv.org/pdf/1805.09604.pdf https://arxiv.org/pdf/1805.09604.pdf 2018 * https://ipads.se.sjtu.edu.cn/_media/publications/fidelius_hpca18.pdf https://ipads.se.sjtu.edu.cn/_media/publications/fidelius_hp... 2018 * https://seclists.org/fulldisclosure/2019/Jun/46 https://seclists.org/fulldisclosure/2019/Jun/46 2019 * https://www3.cs.stonybrook.edu/~mikepo/papers/severest.asiaccs19.pdf https://www3.cs.stonybrook.edu/~mikepo/papers/severest.asiac... 2019 * https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf 2019 * https://arxiv.org/pdf/1908.11680.pdf https://arxiv.org/pdf/1908.11680.pdf 2019 * https://arxiv.org/pdf/2004.11071.pdf https://arxiv.org/pdf/2004.11071.pdf 2020 Any enclave technology will be reliant on the underlying security of the processor itself. Someone was going to have to go first. Intel happened to take greater risks in the name of performance, and all of their technologies (including their first-to-market enclave technology) are suffering reputational hits as a result. I'll also just mention that CrossTalk is the more interesting vulnerability affecting SGX that was disclosed today.
- usmannk 6y ago
  Oh huh, I see. Thanks for the papers. "Someone was going to have to go first. Intel happened to take greater risks in the name of performance, and all of their technologies (including their first-to-market enclave technology) are suffering reputational hits as a result." Very true, and a point worth making. Just curious, do you work closely with SGX/SEV? You were quick with the links!
anonymousDan 6y ago

akersten 6y ago

Remember, SGX is not a security feature. It is a DRM feature meant to take control away from the owner of the machine and give it to content owners. Happy to see every successful attack against this module, and hoping that Intel decides to just ditch it entirely.

lxgr 6y ago
Oh boy, here we go again. No, SGX is a technology allowing for the trusted execution of code in an untrusted environment. DRM is one potential application of that technology. See also the comment section on literally _every other HN submission with SGX in the title_, for example here: https://news.ycombinator.com/item?id=22495251 https://news.ycombinator.com/item?id=22495251
- akersten 6y ago
  Yes, indeed here we go again, because I fundamentally disagree that "allowing the trusted execution of code" is any different than DRM. A rose by any other name. I believe a user should have full control over the hardware they own. SGX and other enclaves are a direct affront to that, and I won't give up the fight. If you need a "trusted execution" of code, run it on a server you control.
  - _jal 6y ago
    > If you need a "trusted execution" of code, run it on a server you control. What CPU do you use for this purpose?
    - akersten 6y ago
      I understand the implication here to be "how can you trust your own hardware anyway," and the answer is "of course in theory you can't." Even if you had SGX and wrote your algorithm or whatever to run in it, if your hardware's compromised, the horse has left the stable. Your proprietary algorithm and input that you developed on the compromised hardware are already available to the attacker. So having SGX locally is not going to help. At the end of the day, SGX is not going to defend a proprietary computation if the input and algorithm are already compromised.

mmm_grayons 6y ago

Boy, I'd love to see Moxie's comment on this after years of shilling SGX. I was always disappointed by that and never understood why someone as otherwise-bright as him went for it.

anonymousDan 6y ago
There have been several attacks like this already (and more likely more to come). The nice thing about the SGX design is many of these issues can be fixed immediately with a microcode update. Now if an attack is announced that can't be fixed with a microcode update that is another story :). In general, protecting against these kinds of attacks for any enclave is a hard problem, but it is an active area of research and there are already research proposals for more side channel resilient enclave designs (e.g. see the Keystone project from Berkeley). I expect some of these mitigations will be incorporated into future iterations of SGX, but it will take time.
- mmm_grayons 6y ago
  You're right, and the idea of a secure enclave is not an inherently bad one. What is bad is treating it as an unassailable fortress, as in signal's address book feature. There's a difference between using it to make critical parts of existing computations more secure and using it to do stuff one wouldn't otherwise do.
  - dane-pgp 6y ago
    > You're right, and the idea of a secure enclave is not an inherently bad one. Maybe it is when you're trusting private keys and proprietary technology controlled by a single entity that may be subject to commercial and political pressures that make their motives not aligned to yours.
    - anonymousDan 6y ago
      I hope you're not typing that on an Intel processor :)

makomk 6y ago

This is one of two lovely side-channel vulnerabilities in Intel processors released today. Apparently they also leak RDRAND and RDSEED data across cores and took 18 months to fix it: https://www.vusec.net/projects/crosstalk/ https://www.vusec.net/projects/crosstalk/

Dunedan 6y ago
> The mitigation locks the entire memory bus before updating the staging buffer and only unlocks it after clearing its content. Entire memory bus as in entire access to any kind of shared memory (shared CPU caches, RAM, ...)? If yes, wow, that's a pretty desperate mitigation. Doesn't that starve large parts of the whole CPU whenever an affected, but mitigated instruction is executed, as all other cores can't interact with memory anymore for the duration of this execution? Doesn't that also open the ability to "DoS" CPUs by constantly executing such instructions?
- 0x0 6y ago
  Hmm, now I wonder if this could turn into a F00F-like bug? What would LOCK REP RDRAND or just REP CPUID do...
  - strstr 6y ago
    You can still acknowledge interrupts in between, so hardware watchdogs will prevent this.
- the8472 6y ago
  You can already do that with split locks, which also lock the memory bus.
  - rigtorp 6y ago
    Yeah, split locks have a huge performance impact, especially with high core counts: https://rigtorp.se/split-locks/ https://rigtorp.se/split-locks/ Fortunately the Linux kernel can kill offenders with SIGBUS: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Split-Locks-Detection https://www.phoronix.com/scan.php?page=news_item&px=Linux-Sp...

deleted 6y ago

[deleted]

exabrial 6y ago

> Our bot provides Attestation as a Service (AaaS) slow clap

deleted 6y ago

[deleted]

jiveturkey 6y ago

Fixed in January. https://blogs.intel.com/technology/2020/06/ipas-security-advisories-for-june-2020/ https://blogs.intel.com/technology/2020/06/ipas-security-adv... > Finally, in January 2020 we released INTEL-SA-00329 addressing two side-channel issues. Specifically, CVE-2020-0549 addressing an issue called “L1D Eviction Sampling” which has been referred to by researchers as “CacheOut”. The CacheOut researchers recently informed us of a new paper referred to as SGAxe. It is important to note that SGAxe relies on CVE-2020-0549 which has been mitigated in microcode (confirmed by the researchers in their updated CacheOut paper) and distributed out to the ecosystem. And from the CacheOut paper: > Finally, Intel had indicated that microcode updates mitigating the root cause behind CacheOut will be published on June 9th, 2020. We recommend these be installed on all affected Intel platforms to properly mitigate CacheOut. The above blog is indeed dated june 9, however it indicates that the fix was made available, and verified, back in January. I find fault, or at minimum a conflict, between the researchers publication as of june 9, and Intel's statement on the same date. Pretty horrible. I especially dislike that the paper has a section called "Current Status", while the paper is undated as is the norm for academic papers of this type. The "Current Status" isn't 100% clear but appears to be current as of November 2019, so yes this would be in advance of both the June 9 supposed date and the apparent January actual date. Perhaps the paper linked on the sgxaxe website isn't the "updated CacheOut paper" that Intel refers to.