I just watched the recorded stream about SGX and I came up with two ways to bypass SGX that were not mentioned.
Everywhere below read "code" as "binary code", not "source code"
First is a software technique: if SGX does not control the stack of the program, we can inspect the stack or trap stack modifications to obtain the locations of function end/start positions and "execute" arbitrary code using "return-oriented programming".
You can read about return-oriented programming in length from this pdf: https://cseweb.ucsd.edu/~hovav/dist/rop.pdf, but I will describe the technique in a few words:
if you control the stack, you can set a return pointer to an arbitrary position in the program, which, in general, leads to arbitrary code execution from within the program space. Instructions may be read starting from different locations and may completely change the meaning of the code. This may be hard, but not impossible if the program code is not known.
The second one is in the hardware, but it is much cheaper than reversing a CPU:
An expensive beefy unbreakable Intel CPU decrypted the secret program code and put it into a cheap RAM module. Since RAM is much easier to produce and "hack", we can read the program code from physical RAM, or inject arbitrary code directly into the physical RAM. Of course, this won't work if SGX decrypts and encrypts memory on the fly which is ridiculously expensive computing-wise.
Everywhere below read "code" as "binary code", not "source code"
First is a software technique: if SGX does not control the stack of the program, we can inspect the stack or trap stack modifications to obtain the locations of function end/start positions and "execute" arbitrary code using "return-oriented programming".
You can read about return-oriented programming in length from this pdf: https://cseweb.ucsd.edu/~hovav/dist/rop.pdf, but I will describe the technique in a few words:
if you control the stack, you can set a return pointer to an arbitrary position in the program, which, in general, leads to arbitrary code execution from within the program space. Instructions may be read starting from different locations and may completely change the meaning of the code. This may be hard, but not impossible if the program code is not known.
The second one is in the hardware, but it is much cheaper than reversing a CPU:
An expensive beefy unbreakable Intel CPU decrypted the secret program code and put it into a cheap RAM module. Since RAM is much easier to produce and "hack", we can read the program code from physical RAM, or inject arbitrary code directly into the physical RAM. Of course, this won't work if SGX decrypts and encrypts memory on the fly which is ridiculously expensive computing-wise.
QEMU, a software virtual machine, already emulates SGX. Unless I'm missing something, if you can run the game inside a QEMU VM without being detected as a VM (the tricky part), you'll be able to inspect the hidden state all you like.
Edit: This exact thing was brought up on the stream. This is what I get for pausing the video to investigate and comment!
Edit: This exact thing was brought up on the stream. This is what I get for pausing the video to investigate and comment!
Edited by skeeto
on
You probably missed the stream, and your question was addressed, and the answer is that QEMU does not have the access to Intel-signed key, so
1) application that require SGX won't accept key from your "virtual SGX"
2) SGX gives CPU-based memory protection, so if you run the emulator with hardware acceleration and "real" SGX instructions, QEMU won't have access to the protected memory.
1) application that require SGX won't accept key from your "virtual SGX"
2) SGX gives CPU-based memory protection, so if you run the emulator with hardware acceleration and "real" SGX instructions, QEMU won't have access to the protected memory.
SGX is a mathematically sound concept, so debating whether it's crackable is largely pointless. Either
1) Intel did not make any mistakes in the implementation, in which case it is not crackable without a hardware attack, or
2) Intel did make a mistake in the implementation, and when people find it, they will attack the mistake and that will be the crack.
But the theory of what is going on here is not attackable in software, unless you solve the public key factoring problem, and hey, if you do that, that's epic for a lot of other reasons :)
- Casey
1) Intel did not make any mistakes in the implementation, in which case it is not crackable without a hardware attack, or
2) Intel did make a mistake in the implementation, and when people find it, they will attack the mistake and that will be the crack.
But the theory of what is going on here is not attackable in software, unless you solve the public key factoring problem, and hey, if you do that, that's epic for a lot of other reasons :)
- Casey
Edited by Casey Muratori
on
Casey, judging from your reply I can only infer that you stopped reading my post starting from "software technique".
What I suggest is not attacking SGX itself, not extracting keys from the CPU, not attacking cryptographically sound systems, but accessing the decrypted data by other means.
I suggest two independent ways that allow this:
1) if stack is not protected by SGX: modify/inspect the stack to exploit the program code
2) if data is not encrypted in physical memory: extract the data directly from physical memory
- Igor
What I suggest is not attacking SGX itself, not extracting keys from the CPU, not attacking cryptographically sound systems, but accessing the decrypted data by other means.
I suggest two independent ways that allow this:
1) if stack is not protected by SGX: modify/inspect the stack to exploit the program code
2) if data is not encrypted in physical memory: extract the data directly from physical memory
- Igor
Did you even read the PDF?
The stack used by "enclave" code (the code that is encrypted) is inside the enclave. The separation is like user code vs. kernel code with explicit entry and exit.
It's fast enough to encrypt/decrypt data as it gets written out and pulled in from main physical memory. There are existing AES instructions to use for normal data, it's not unreasonable to assume they use it for fetching main memory data. The performance hit won't be that bad over the 200 cycles they are already waiting for RAM.
The stack used by "enclave" code (the code that is encrypted) is inside the enclave. The separation is like user code vs. kernel code with explicit entry and exit.
It's fast enough to encrypt/decrypt data as it gets written out and pulled in from main physical memory. There are existing AES instructions to use for normal data, it's not unreasonable to assume they use it for fetching main memory data. The performance hit won't be that bad over the 200 cycles they are already waiting for RAM.
Yes, all the memory in enclave will be encrypted. That includes stack, data and code. It is still encrypted during execution. As for performance Intel for sure have thought about it. This is nice presentation from Intel that talks about this stuff: https://software.intel.com/sites/default/files/332680-002.pdf
Check out pages 32-33 which explictly mentions that code will be encrypted in memory.
And checkout pages 163-201 that gives some overview about memory encryption mechanism.
It doesn't talk much about where decryption mechanism happens, but I could imagine that could happen when memory is loaded in L1 cache. Then you could decrypt whole cache line and mark it "protected" (so no other enclave or regular system doesn't access it).
While ROP attack is still valid (because we all know how easy is to make buffer/stack overflow errors), making actual ROP chain will be very hard if not impossible task. Because code on disk will be encrypted, so you cannot analyze that. Once it is loaded into enclave it is still encrypted (probably with different key), and inaccessible from other system and other enclaves. So you cannot analyze live system to figure out data for ROP.
@skeeto: QEMU won't help here. All the trust will be based on that secret Intel key. Including encryption key on code. If you don't have that (and QEMU won't), you won't be able to load code to execute. Of course you'll be able use QEMU to develop SGX code, but that will include some kind of dummy/qemu-specific key. While I don't know exact protocol they use for this, I have no doubt Intel people have serious cryptographers that designed this protocol well.
Check out pages 32-33 which explictly mentions that code will be encrypted in memory.
And checkout pages 163-201 that gives some overview about memory encryption mechanism.
It doesn't talk much about where decryption mechanism happens, but I could imagine that could happen when memory is loaded in L1 cache. Then you could decrypt whole cache line and mark it "protected" (so no other enclave or regular system doesn't access it).
While ROP attack is still valid (because we all know how easy is to make buffer/stack overflow errors), making actual ROP chain will be very hard if not impossible task. Because code on disk will be encrypted, so you cannot analyze that. Once it is loaded into enclave it is still encrypted (probably with different key), and inaccessible from other system and other enclaves. So you cannot analyze live system to figure out data for ROP.
@skeeto: QEMU won't help here. All the trust will be based on that secret Intel key. Including encryption key on code. If you don't have that (and QEMU won't), you won't be able to load code to execute. Of course you'll be able use QEMU to develop SGX code, but that will include some kind of dummy/qemu-specific key. While I don't know exact protocol they use for this, I have no doubt Intel people have serious cryptographers that designed this protocol well.
Edited by Mārtiņš Možeiko
on
Actually there is a "read from enclave" instruction but that only works for enclaves marked debugable.
You can also step through debugable enclaves. So emulator is not needed.
You can also step through debugable enclaves. So emulator is not needed.
Sure, extra debugging support is good. But I would be very surprised if you can mark arbitrary enclaves debugable. That would defeat whole purpose of SGX.
Btw, Windows 10 already has API for SGX, no need to wait for newer Windows versions: http://www.alex-ionescu.com/Encla...0Windows%2010%20Fall%20Update.pdf
https://msdn.microsoft.com/en-us/...ary/windows/desktop/mt592870.aspx
https://msdn.microsoft.com/en-us/...ary/windows/desktop/mt592866.aspx
Also one important "feature" of SGX Casey didn't mention on stream - CPU will run in enclave only code that is signed by Intel. You won't be able to write whatever you want for SGX. When you are developing some code that wants to use SGX, you will need to contact Intel to "allow" Intel CPUs to run this code. So this technology can and will be strictly controlled by Intel. Here's a good overview on this: https://jbeekman.nl/blog/2015/10/intel-has-full-control-over-sgx/
Good read on SGX (and other Intel technologies like TPM, ME) is this paper from MIT: https://eprint.iacr.org/2016/086
https://msdn.microsoft.com/en-us/...ary/windows/desktop/mt592870.aspx
https://msdn.microsoft.com/en-us/...ary/windows/desktop/mt592866.aspx
Also one important "feature" of SGX Casey didn't mention on stream - CPU will run in enclave only code that is signed by Intel. You won't be able to write whatever you want for SGX. When you are developing some code that wants to use SGX, you will need to contact Intel to "allow" Intel CPUs to run this code. So this technology can and will be strictly controlled by Intel. Here's a good overview on this: https://jbeekman.nl/blog/2015/10/intel-has-full-control-over-sgx/
Good read on SGX (and other Intel technologies like TPM, ME) is this paper from MIT: https://eprint.iacr.org/2016/086
Edited by Mārtiņš Možeiko
on
mmozeiko
When you are developing some code that wants to use SGX, you will need to contact Intel to "allow" Intel CPUs to run this code. So this technology can and will be strictly controlled by Intel.
That ameliorates some of my concerns with it, actually. This means that it's not a place where malware can hide. Without this restriction, it would take only one small security hole in the OS and you have a rootkit that not even the OS, let alone anti-malware scanners, can find or reverse-engineer.
On the other hand, what's the chance that Intel will sign code written by a competitor, such as AMD? And putting the tinfoil hat on, what's the chance that the next Stuxnet somehow gets signed, and Intel has no idea how it happened?
It's then entirely possible that the "public" keys for encryption never leave enclaves.
Say Intel's key extraction enclave will only send it out when it has established a secure channel to another enclave (verified with public/private keys embedded in the enclaves) and the other enclave will only encrypt for Intel signed keys.
This way they can prevent you pulling out the public key from a processor by refusing to create enclaves for code that have the instruction to pull out said key. While still letting encryption happen on the distributor's servers.
Say Intel's key extraction enclave will only send it out when it has established a secure channel to another enclave (verified with public/private keys embedded in the enclaves) and the other enclave will only encrypt for Intel signed keys.
This way they can prevent you pulling out the public key from a processor by refusing to create enclaves for code that have the instruction to pull out said key. While still letting encryption happen on the distributor's servers.
I'm just wondering if anybody knows the answers to a few questions about sgx.
Is it possible to store your own keypair in the cpu, or to replace the current cpu keypair with your own?
I've seen somewhere in the released documents that the expected performance penalty to run a program in an enclave is ~ %10. I was wondering if it is possible to run the whole system (os, all programs) in an enclave, and if so, would the performance penalty be greater?
If you could store your own keypair and have the whole system in an enclave, then you could do whole system encryption, a stronger version of whole disk encryption that is resistant to attacks like cold boot. This would be useful for laptops, so that you could just suspend instead of having to hibernate, or turn off to have the data on the laptop protected, and also for servers running in an untrusted data centre.
As much as I don't like how sgx could be used against me, it could potentially be very useful for me.
Just as a side note, it's kind of interesting that drm and platform security are essentially the same, only differing by which side someone is on. (i.e. for drm it is game producers/distributors vs. a user with physical access, and for platform security it is a user vs. people who have physical access to the user's machine.)
Is it possible to store your own keypair in the cpu, or to replace the current cpu keypair with your own?
I've seen somewhere in the released documents that the expected performance penalty to run a program in an enclave is ~ %10. I was wondering if it is possible to run the whole system (os, all programs) in an enclave, and if so, would the performance penalty be greater?
If you could store your own keypair and have the whole system in an enclave, then you could do whole system encryption, a stronger version of whole disk encryption that is resistant to attacks like cold boot. This would be useful for laptops, so that you could just suspend instead of having to hibernate, or turn off to have the data on the laptop protected, and also for servers running in an untrusted data centre.
As much as I don't like how sgx could be used against me, it could potentially be very useful for me.
Just as a side note, it's kind of interesting that drm and platform security are essentially the same, only differing by which side someone is on. (i.e. for drm it is game producers/distributors vs. a user with physical access, and for platform security it is a user vs. people who have physical access to the user's machine.)
Edited by people
on