Researchers use Intel SGX to put malware beyond the reach of antivirus software

https://arstechnica.com/gadgets/2019/02/researchers-use-intel-sgx-to-put-malware-beyond-the-reach-of-antivirus-software/

by protomyth • 7 years ago

86 21 7 years ago

arstechnica.com

fao_• 7 years ago

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

nine_k• 7 years ago

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.

gruez3• 7 years ago

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• 7 years ago

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.

gruez3• 7 years ago

but you can read/write all memory

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

caf• 7 years ago

Forget antivirus, you could use this to build ransomware that doesn't need C2 at all. The enclave itself can wait for confirmation of the bitcoin transfer and then release the decryption key.

Sure you can stop it talking to the outside world, but you can't force it to give up the key.

ngneer• 7 years ago

The paper is interesting in that it shows the extent to which an untrusted enclave is capable of owning its host. This is not an attack within the adversary model of SGX, as the authors state, because an enclave can, by design, write to host memory. Typically, this would be enough for people to assume that arbitrary code execution would be possible, but, these researchers went through the exercise of actually implementing the attack. They highlight a useful property of TSX when invoked inside an enclave, allowing them to determine the accessibility of host memory addresses (termed caves), without incurring exceptions. What is interesting about the paper is the creation of a code reuse attack to robustly subvert control flow and create arbitrary execution in the host context.

amluto3• 7 years ago

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

phkahler2• 7 years ago

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.

ENOTTY2• 7 years ago

The computing model enabled by SGX (and other mechanisms like it) require more careful specification of the entities involved and the trust relationships between each other.

In the cloud situation, the customer doesn't trust the cloud provider beyond just running his/her software (but inherently trusts him/herself). The cloud provider doesn't trust the customer to respect its isolation boundaries and must defend itself from SGX enclaves (and indeed all other client software) appropriately.

haikuginger• 7 years ago

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.

phkahler2• 7 years ago

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.

throwaway2048• 7 years ago

Don't forget DRM that the users don't want.

peter_d_sherman• 7 years ago

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

giomasce• 7 years ago

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• 7 years ago

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.

Researchers use Intel SGX to put malware beyond the reach of antivirus software

Related Stories