
How SGX Fails in Practice - gbrown_
https://sgaxe.com/
======
makomk
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
> 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?

~~~
JoachimS
Exactly what I wonder too. Can't the fix be used as an attack vector. At least
infer disruptions to trigger timeout events, add execution time variance.

And wouldn't you be able to detect RdRand instruction execution for (for
example) key generation. Pinpointing when processes perform sensitive
operations.

And, would it be possible to use RdRand execution as a time based exfiltration
channel? Run a timing loop in one process on one core. Use RdRand reading with
different frequency in a second process to (using morse code or similar) to
encode information. The first process use its timing loop to recover the
information.

------
usmannk
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?

~~~
lima
SEV is exciting because it has a much better cost-to-benefits ratio.

It provides useful defense in depth without requiring any changes to the
application stack - you can run regular VMs with syscalls, plenty of memory
and high-bandwidth IO.

SGX, on the other hand, is extremely limited and notoriously hard to target.
It's even harder these days - you need specialized compilers and coding
techniques to mitigate a number of attacks that can't be fixed by a microcode
update.

I reckon it's almost impossible to do serious SGX work these days without
being under NDA with Intel such that you can work on mitigations during
embargoes for the never-ending stream of vulnerabilities.

~~~
thu2111
_SEV is exciting because it has a much better cost-to-benefits ratio._

I think that's not actually true.

The problem is if you believe SGX "needs" these sorts of defences/mitigations
then so does SEV, because SEV VMs are not magically immune to side channel
attacks and in fact suffer far more than just micro-architectural side
channels because they also leak all disk and memory access patterns, network
access patterns and so on. These sorts of side channels aren't the
responsibility of any CPU to fix but are remarkably powerful.

Sometimes it feels like SGX gets placed under a rather nasty double standard.
Enclaves are "hard" because you "must" mitigate side channel attacks. SEV VMs
are "easy" because nobody even tries at all. Indeed they cannot try - normal
software isn't built to eliminate app level side channels. That's why enclaves
are special programs to begin with.

If you are happy to use existing non-hardened software though and just take
the defence in depth argument, well, no problem - you can use SGX too. There
are things like SCONE that let you run existing software inside enclaves.
Unlike SEV, SGX is actually fixable when security bugs are found so it's
meaningful to talk about using it. SEV has been theatre so far. It's not
renewable, there's no equivalent of TCB recovery so nobody bothers trying to
attack it because it's already been broken in unfixable ways before.

~~~
yths
You are right about the double standard but using enclaves means restructuring
your application. Even SCONE requires porting. SEV gives you the warm and
fuzzy feeling that you are doing something to improve security without having
to do a lot of work, assuming that your favorite OS version has been ported to
run in a "secure" VM.

~~~
lima
It's apples and oranges.

SEV is useful for defense in depth and absolutely not comparable a secure
enclave like SGX or TrustZone.

However, it results in significant security gains with almost no extra effort.

Secure enclaves like SGX are designed with much stronger security guarantees
and are therefore hard and expensive to use, and they're regularly broken due
to design issues that may be impossible to fix, making it a bad investment.

~~~
thu2111
The problem is, it's not really clear it results in significant security
gains.

SEV (a hypothetical version that wasn't broken) would give you encrypted
memory and some basic remote attestation protocols.

The point of this is to stop a cloud vendor from peeking into your VM.

But the problem is, none of the software inside your VM is designed to resist
attacks by a malicious hypervisor. This isn't just side channel attacks but
also so-called Iago attacks. This is where a formerly higher privileged piece
of software is trying to break into a lower privileged bit of software by
manipulating the API responses.

For SGX it was shown that running a whole standard Linux process inside an
enclave and relaying system calls outside (i.e. a similar arrangement to what
SEV does) could lead to the process being hacked the moment it did something
trivial like call malloc(). The reason was, the software didn't expect the
kernel to try and manipulate it via syscall return values because there is no
point normally.

In SEV we have the same issue. Hypervisors were previously more privileged
than kernels. Therefore kernels and apps aren't designed on the assumption of
a malicious hypervisor. It's highly likely that not only side channel attacks
but also Iago attacks apply there too.

Now you could say, well, one step at a time, maybe it doesn't matter, better
than nothing etc. Sure. All true. At the very least it complicates the attack
process and is more likely to generate an audit trail inside the cloud vendor.

But actually Intel had a somewhat comparable solution for a long time called
TXT. It lets you start a trusted/measured hypervisor that can then supervise
VMs on the box. This is in some ways stronger as you can actually check the
hypervisor won't attack the VMs. But it's hardly used because cloud vendors
use proprietary hypervisors, and actually the threat model people care about
is "malicious cloud vendor trying to break into the VM", not "incremental
security improvement of unknown utility".

I suspect Intel will implement encrypted memory for VMs at some point anyway
because of the viewpoint you raise here being quite common - "I'll encrypt the
RAM for free and then I'm done" although of course it needs tooling
integration as well. It's not actually quite for free.

But I guess if this takes off then AMD will start to see a lot of research
papers where people break into the encrypted memory space in various clever
ways, and of course, you're also vulnerable to any exploits in the software
stack on the VM itself. That was the main reason the security community ended
up with the SGX type model. When your trusted computing base is an entire
virtual machine it doesn't give you much because VMs have so much software in
them, they get hacked all the time. The idea of enclaves is you design your
app so the bulk of the software stack is untrusted, and only small parts get
to directly touch sensitive data.

~~~
lima
I fully agree with all of what you said. There's a big difference between "hey
can you dump this VM for me please" and "hey please implement this paper to
dump this customer's VM" and it provides cloud providers with plausible
deniability when law enforcement comes knocking. It's certainly useless once
your threat model includes grad students with lots of time at their hands.

The "trusted hypervisor" approach is actually what my company is working on,
with SEV just as a convenient attestation mechanism and nice defense in depth.

Yes, with SEV the guest OS has to assume that the emulated hardware is
untrusted and I'm quite sure that no OS was built with this threat model in
mind. It's not as bad as proxying syscalls from SGX to the host kernel because
there's a lot smaller attack surface, but I bet you could find a hundred ways
to compromise a stock Linux kernel running in SEV.

I'm more optimistic about unikernels written in say, Rust, which would still
be a much friendlier API than SGX.

~~~
thu2111
Ah, my company is working with SGX. Perhaps that explains our difference of
view ;)

The hypervisor ABI is quite large, perhaps not as large as a kernel's but it
doesn't really make sense to expose the same API to secure code anyway. For
instance an encrypted VM that then uploads its data somewhere else via raw TCP
sockets doesn't make sense conceptually, even though the API allows it. You
have to use SSL. Likewise an encrypted VM that downloads software updates from
the repositories of a cloud provider, also doesn't make much sense, even
though nothing in the tech stops it.

The nice thing about an enclave is you can understand completely the data
flows in and out by examining the interface. That does mean compiling existing
software for it will die with unimplemented functions. But those errors are
probably telling you something meaningful - i.e. if the code attempts to call
socket() or open() then you _can_ just relay them outside the enclave, but it
makes more sense to think about what you're really trying to do.

It's a more purist approach with worse compatibility, I agree. It's really
focused on finding the minimal TCB of your program and excluding all else,
like how Chrome moves the rendering engine out of its TCB. I suspect many apps
can be designed in such a way that almost all of the code is untrusted, but
it's a bit of a frontier and takes quite a bit of skill.

------
pstrateman
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
> 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
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.

------
akersten
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
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
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.

~~~
lxgr
Trusted computing isn't so much about control as it is about
trust/attestation. You can run privileged malware on your computer without
trusted computing. On the other hand, you can also sandbox trusted computing.

If you don't want to run somebody else's code on your computer – don't!
(Chances are you're not a cloud provider and nobody is asking you to, anyway.)
If you oppose DRM – don't consume content protected by it, whether the DRM is
implemented in SGX, TrustZone or just in obfuscated software.

Don't get me wrong, I am not the biggest fan of DRM either (I personally see
it as an evil, maybe a necessary one though). But shunning the entire field of
trusted computing is a bit like opposing theoretical physics because it
ultimately has brought us nuclear weapons.

~~~
akersten
I'm not entirely against the concept of trusted computing, but it's hard to
believe that "trusted computing" as we know it today is so innocuous when it's
included on consumer CPUs. Why not keep it as a premium feature for server-
class CPUs instead?

~~~
uluyol
I don't think SGX is available on any consumer CPUs.

~~~
matheusmoreira
My laptop has an Intel i7-8750H CPU.

[https://ark.intel.com/content/www/us/en/ark/products/134906/...](https://ark.intel.com/content/www/us/en/ark/products/134906/intel-
core-i7-8750h-processor-9m-cache-up-to-4-10-ghz.html)

> Intel® Software Guard Extensions (Intel® SGX)

> Yes with Intel® ME

I have it disabled in the firmware settings.

------
jiveturkey
Fixed in January.

[https://blogs.intel.com/technology/2020/06/ipas-security-
adv...](https://blogs.intel.com/technology/2020/06/ipas-security-advisories-
for-june-2020/)

> 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.

------
mmm_grayons
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
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
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
> 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
I hope you're not typing that on an Intel processor :)

~~~
dane-pgp

      $ grep vendor_id /proc/cpuinfo
      vendor_id       : AuthenticAMD

------
exabrial
> Our bot provides Attestation as a Service (AaaS)

slow clap

