
Researchers use Intel SGX to put malware beyond the reach of antivirus software - protomyth
https://arstechnica.com/gadgets/2019/02/researchers-use-intel-sgx-to-put-malware-beyond-the-reach-of-antivirus-software/
======
nine_k
So, when malware gets enough privileges, it can use SGX like legitimate
software. If it decides to hide some info in an SGX enclave, nothing else can
access it.

Compare: if malware decides to use strong encryption, nothing else can decrypt
it.

To me, this is how reliable protection mechanism (secure enclave, encryption)
should work. It's either unbreakable by existing means by design, or mostly
useless.

It's not the encryption library's work to decide if it encrypts for a good
purpose or for a bad purpose. Same for SGX. Protection from malware should
occur on a (much) higher level. Once certain code is admitted as legitimate by
that higher level (e.g. an OS), the CPU should faithfully execute it, and it
does.

------
gruez
What's the use here? If you want to get anything done you'd have to exit the
enclave to do syscalls, at which point antivirus can detect what you're doing.
I guess you can use it to obfuscate code flow and C2 communications but you
already do that with obfuscators, which doesn't require a signing certificate
from intel

~~~
tpolzer
You cannot do syscalls, but you can read/write all memory, which means you can
make some arbitrary (trusted) process your victim, executing code in a ROP
manner and antivirus won't see a thing.

~~~
gruez
>but you can read/write all memory

Source? AFAIK programs running inside don't have kernel/DMA access.

~~~
UncleEntity
> The enclave code does, however, have the ability to read and write anywhere
> in the unencrypted process memory

Source: TFA

~~~
gruez
Strange, I skimmed through a few SGX code samples[1] and they're all C
programs that pass data through an API rather than pointer passing. The
article states that they have access to all memory and it doesn't seem like
Intel refuted it, so I guess we can assume it's true. That said, I find it
strange that enclaves have access to all memory, when all it needs is access
to its own protected region. If that's true, that seems like an oversight on
Intel's part, especially since they already have well defined interfaces for
passing data between trusted/untrusted code.

[1] [https://github.com/digawp/hello-enclave](https://github.com/digawp/hello-
enclave)

[1] [https://software.intel.com/en-us/articles/sgx-intro-
passing-...](https://software.intel.com/en-us/articles/sgx-intro-passing-data-
between-app-and-enclave)

edit:

looks like the article might be mistaken. According to an article on SGX
internals[2], SGX code may only access enclave memory. A similar diagram can
be found in a slide deck [3].

[2] [https://blog.quarkslab.com/overview-of-intel-sgx-
part-1-sgx-...](https://blog.quarkslab.com/overview-of-intel-sgx-part-1-sgx-
internals.html)

[3]
[http://cwfletcher.net/Content/598/lec04_sgx.pdf](http://cwfletcher.net/Content/598/lec04_sgx.pdf)
page 26

~~~
amluto
The SDM is unambiguous: enclaves can access any memory that the host process
can access. The enclave can also modify most of its callers registers,
including RSP, RBP, and RIP. The Intel SDK uses these ability for reasons that
might be considered unwise.

------
amluto
If software runs untrusted enclave code, it needs to sandbox it, full stop.
This research is interesting, but it’s not remotely surprising.

------
peter_d_sherman
In old computers, the entire machine could be controlled by any program. While
this exposed the entire machine for attack by a virus, it also exposed the
entire machine to be thoroughly cleaned by virus checkers, and/or reformatted
and OS reinstalled (again, thoroughly cleaning the machine). When you don't
have that, you've effectively taken control of the machine from the community
of programmers and users and given it to a single gatekeeper... Basically, it
de-democratizes control of computing hardware... Maybe that is desirable to
some users, but it is repugnant to those that feel that if they paid good
money to a vendor for hardware, that they should own and control every bit in
that hardware...

------
phkahler
The Intel response seemed odd. They say you need to only run software from
trusted sources. But if we only run trusted software the need for the enclave
goes away. The only use then is for running code on a machine you dont trust.
In the cloud.

~~~
haikuginger
The trust dynamic is the opposite of what you think - SGX doesn't enable an
enclave that protects the machine owner from the code they execute; it enables
an enclave that protects executed code from the machine owner.

The largest consumer application of this is DRM - modern UHD Blu-Ray playback
on a PC requires a fully SGX-enabled backend; the negotiation to obtain
playback keys and the decryption of the on-disc content is done in the SGX
enclave.

~~~
phkahler
In that case the DRM code running in your PC is in a hostile environment. That
is someone else's code running on my host and fearing me. The dynamic is
exactly as I described. The question is: Whose code are you going to run on
your machine? And why is there a trust issue?

We've already seen the Sony rootkit fiasco, so it doesn't seem unfair to say
one should not trust what DRM providers are doing. We should definitely not
let their malicious garbage run in a secure onclave where you can't tell what
it's doing as suggested by these researchers.

------
fao_
Well... yeah. That's pretty much the first use I thought of when I heard of
enclaves.

------
giomasce
How does a software running under SGX know that it is in a "real" processor
enclave, and not in an enclave emulated around it which allows the emulator to
actually peek inside and know what the software is doing? Virtual machines are
already a thing, and if the virtual machine emulates the SGX interface it can
very well support the extraction of memory encryption keys too...

~~~
taejo
You're right, of course, that the software can't know, since any test it did
could simply be emulated to return the right result. But anyone that software
talks to outside of the emulation can know. IIRC (I last looked at SGX a few
years ago, and have moved out of cryptography subsequently) the processor has
keypair with the corresponding certificate signed by Intel. The code running
inside SGX can then create and distribute a public key with a certificate
proving (if you trust Intel) not only that the keypair was generated inside
SGX, but also which code has access to it, and a server can encrypt data using
that key, and only that code will be able to decrypt it.

