Researchers use Intel SGX to put malware beyond the reach of antivirus software | Hacker News Reader

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

arstechnica.com

86 pointsprotomyth21 comments

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.

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

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.

>but you can read/write all memory

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

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

Source: TFA

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

[1] https://software.intel.com/en-us/articles/sgx-intro-passing-...

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

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

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.

Process address spaces don't include (nearly all of) the kernel address space anymore thanks to Meltdown.

This isn’t relevant here. Enclaves can access any memory that the user host process can, plus their own memory. The kernel is off limits, except insofar as the enclave can exploit Meltdown.

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.

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.

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

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

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.

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.

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.

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.

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

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

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

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.

Reply on news.ycombinator.com