SGX Enclave Exploit Analysis and Considerations for Defensive SGX Programming
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 287 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/57124 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Information securityProjective planePresentation of a groupMathematical analysisComputer programmingExploit (computer security)Template (C++)Computer animation
00:35
Stack (abstract data type)Boundary value problemRule of inferenceInformation securitySoftwareJSONXML
01:01
Machine codeSoftware developerWeb pageDifferent (Kate Ryan album)Scaling (geometry)Computer animation
01:31
MereologyGame controllerInterface (computing)Point (geometry)Integrated development environmentEncryptionCategory of beingBoundary value problemSurfaceMachine codeInformation securityCartesian coordinate systemComputer animation
02:47
Link (knot theory)Machine codeControl flowBoundary value problemInformationException handlingVirtual realityHTTP cookieInformationMereologyMemory managementInformation securityVirtualizationWebsiteMachine codeGame controllerBoundary value problemDataflowAsynchronous Transfer ModeStack (abstract data type)Software bugException handlingBuffer solutionSoftware developerBuffer overflowLibrary (computing)FunktionalanalysisSource codeCompilerElectronic program guideSubject indexingTable (information)Addition
06:28
HexagonLink (knot theory)Link (knot theory)Address spaceSemiconductor memoryElectronic mailing listMachine codeHoaxType theoryMemory managementInjektivitätComputer animation
08:01
Read-only memoryBoundary value problemFormal verificationChainMachine codeBoundary value problemMemory managementInjektivitätFreewareSoftware developerFunktionalanalysisSimilarity (geometry)Address spaceXML
08:49
Buffer solutionMachine codeComputer programmingComputer animation
09:35
Machine codeBuffer overflowMereologyHTTP cookieDataflowBuffer overflowMachine codeMereologyComputer programmingInformation securitySubject indexingXML
10:29
Address spaceVariable (mathematics)Diagram
11:12
MereologyAddress spacePredictionRead-only memoryBit rateSoftware developerRandomizationPointer (computer programming)Control flowPoint (geometry)Web pageBuffer overflowMachine codeSoftware development kitLogicVariable (mathematics)Computer hardwareParameter (computer programming)Client (computing)Open setInformation securityBinary fileMathematical analysisRevision controlMereologyRun time (program lifecycle phase)Software developerCrash (computing)InformationSpacetimeMappingBoundary value problemRight angleProjective planeRandomizationRange (statistics)Address spaceType theoryKernel (computing)Multiplication signScheduling (computing)System administratorBuffer overflowSoftware bugConnectivity (graph theory)Computer hardwareDevice driverWritingSemiconductor memoryIntegrated development environmentSimilarity (geometry)Web pageDataflowSoftwareInformation securityXML
16:29
ActuarySoftware testingHTTP cookieCorrespondence (mathematics)Integrated development environmentInformationInformation securityData structureComputer animation
16:57
InformationBuffer solutionHTTP cookieDataflowKey (cryptography)PasswordFunktionalanalysisRandomizationInformation securityData structure
17:59
Data structureComputer configurationCompilerSoftware developerMachine codeCompilerComputer configurationSemiconductor memoryXMLComputer animation
18:29
Pointer (computer programming)Software developerCondition numberBuffer solutionMereologyContent (media)Machine codeMiniDiscAdditionSemiconductor memoryMultiplication signComputer fileComputer animation
19:56
EmailJSONXMLUMLComputer animation
Transcript: English(auto-generated)
00:05
Hello, everyone. I'm Chengda, a security researcher from Intel. I have worked in SGX project for over 10 years. Today I'm going to introduce and explore the analysis on SGX template and also my considerations for defensive SGX programming.
00:27
The exploits in this presentation are all known issues and have already been mitigated in SGX. I will introduce some past attacks, mitigation, defense in-depth, and see what we can learn from these attacks and defense.
00:53
Because one important rule of software security is to learn from mistakes.
01:02
The purpose of this talk is not to attack SGX, but I want to help developers have a better understanding on SGX security, know the difference between inside and outside enclave, and write more scale code for their enclaves.
01:30
There are some basic concepts of SGX and I hope we are on the same page. Intel SGX technology enables applications to run code in a trusted environment.
01:48
So SGX is a TE. The trusted part is called enclave. So this part, enclave, it's encrypted.
02:02
So although the SGX encrypted the trusted part, attacks can still attack enclaves while SGX attacks surface. We can see these are the security properties of enclave.
02:22
Enclave provides confidentiality, integrity, and controlled entry points. But these controlled entry points and the other interface between the trusted and untrusted boundary can still be the attack surface.
02:48
Okay, so the code running within enclave still must be written securely.
03:02
Otherwise, if there are some poor written code, there may be a subject to attack by the attacker outside enclave. The data is to see the traditional bugs inside enclave, such as buffer overflow, runpoint dereference,
03:24
that still cause security problems. But the impact might be different for outside. And another thing is site channel. Although site channel is an important topic, we will not talk the detail today, as we have only 20 minutes.
03:52
So the popular attacks to SGX enclave include code injection, execution, flow change, third-party vulnerabilities, and cross-boundary information leakage.
04:08
You can see the first three items are still traditional attacks or vulnerabilities,
04:20
but sometimes the impact or scope changes, and we will talk about it later. Cross-boundary information leakage is something we need to pay attention to. It is different from traditional software development mode. In TEE, we have trusted part and untrusted part. We need to carefully deal with data across boundaries between trusted part and the untrusted part.
04:52
One major purpose affecting SGX and TEE is to steal secret information,
05:05
to get the secret information from outside, rather than change the privileges. So we also need to bear it in mind.
05:22
And Intel SGX SDK has provided some defense index to developers. We suggest not to disable it. We provide stack cookies, non-execution memories, protection on exception handler, virtual table verification,
05:50
control flow, hardening, or safe un-linking cookies, and our additional boundary checks inside enclave.
06:02
They are provided by customized libraries functions and some compiler options. Most of them are enabled by default, so developers can refer to the developer guide and also our source code to ensure the correct usage.
06:27
So let's see the heap. There are three chunks, A, B, and C. Typically, when there is an overflow in A, you can overwrite B.
06:44
If B is double-freed or use-after-freed, then when B is allocated again, there can be un-linking of double-link list.
07:02
Then cause a well-known write-anything-to-anywhere issue. That means write something you controlled to some address also controlled by you. And the typical defense is the safe unlink. But owning the traditional safe unlink here is not enough.
07:31
Attackers can fake a chunk with suitable pre and the next link to A and C. But its address is pointing outside enclave.
07:43
Although attack cannot achieve write-anything-to-anywhere, but they could successfully mislead inside enclave memory copy code to copy secret outside enclave. That's a new type of heap injection in SGX.
08:07
So our mitigation is to add boundary checks in the un-linking method in malloc and free. We have functions to check if the address is inside enclave or outside enclave.
08:20
So that problem is fixed. But the customers, the developers of enclave might have some similar memory management in high-level. So they should pay attention to this kind of injection from outside.
08:52
Okay, the next popular threat to enclave is ROP. Actually, it's buffer overflow, right?
09:12
Let's first see the ROP. ROP means return-oriented programming. Nothing is
09:21
special, although enclave code is encrypted, but it still contains ROP gadgets. You can refer to the paper of that ROP on the details of the attack. So buffer overflows can use parts of your code as ROP gadgets.
09:44
We have provided spec protections and leveraged ASLR for defense index. So I think the best defense in SGX is to prevent overflows. To ensure buffer overflow protection is the correct way of defensive programming for this kind of issues.
10:11
So if you don't have buffer overflow or any such kind of code execution flow change, then the security implication of ROP is very limited.
10:30
Okay, so ASLR is another problem. If there is an overflow, ASLR can help to mitigate and make the attack much harder.
10:49
SGX enclaves leverage system-level ASLR, but the layers of enclaves are almost fixed.
11:01
That means some offsets between heap, stack, and variables remain the same. So it is better to not rely too much on ASLR. Or you can refer to some solutions like SGS shield or similar projects to enhance the enclave address randomness.
11:36
And ASLR is not supported in trust part. We just leveraged the system-level ASLR.
11:48
So it's not a part of the TCB. So the developers should know that. I think the best practice is to prevent the overflow, prevent the buffer overflow.
12:08
We have some defensive types to ensure you enable them, similar to the ROP. Okay, non-pointer dereference is usually not a big issue outside in the user space.
12:28
But it's usually only cause the OS issue like crash or unexpected abort in the user space.
12:40
Right. But in SGX, similar to the kernel space, non-pointer dereference could cause more serious problems. Like information leakage or even execution flow changes.
13:04
Because driver and OS are out of SGX trust boundary. Attackers can have the ability to change driver and remap zero address to a valid page.
13:23
If you don't have appropriate checks for the non-pointers, you may write something inside enclave to outside or mistakenly use outside arbitrary data which is supposed to be protected by enclave.
13:44
So this is also a good example that security implications changed between SGX and the non-SGX environment. We need to pay attention that the trust component changes.
14:03
When we use SGX for a normal application, then zero driver or OS admin might be their trust part, but in SGX they are not. So attacker can change driver, remap zero address to another address.
14:24
And we have already added support for including zero address to inside enclave memory range. So the developers can directly include zero address into their enclave. And then hardware can provide protections against the runtime mapping.
14:45
Or another simple way of software to fix this is just to check the non-pointed developers correctly by yourself.
15:01
Here is the CVE in OpenSSI. It is non-pointed developers. It is not a high bug for OpenSSI, but it is a high bug for SGX because of the address remapping.
15:27
So when we get a third party CVE from your scanning tools like BTBA, you need to analyze the impact to SGX. Sometimes the impact might be different from outside.
15:44
For example, the non-pointed developers we have just mentioned or some other bugs might affect data across trust boundaries. For those bugs, low issue can be changed to high issue.
16:04
Sometimes you can ignore low issue because of time or schedule for your release, but you must fix high issue. So when you get a third party CVE, you don't need to analyze them to see if the impact is changed.
16:30
The corresponding information leakage is one major threat to SGX. One example is the alignment issue. There could be some holes in the data structure because of alignment.
16:46
It can leak something in the memory. It's probably not a big issue in non-SGX environment. For example, one popular attack might be the leakage of security cookies.
17:02
The holes in the data structure contains the random security cookies of the previous functions. Then if you happen to have a buffer flow in your hands, you may bypass the random security cookies by the information leaked to you.
17:31
But in SGX environment, attackers do not need that. If such structures are copied out into untrusted part, the holes in the structures may have already contained some secret from the enclave.
17:51
Maybe a part of key or maybe some unclear the password.
18:01
So Intel SGX SDK has provided some mitigations, memory clear function, and we also enabled compiler options for PAC-1. But users enclave code might have their own alignment.
18:22
If that is the case, then please remember to clear your secret after you use them. Okay, the last problem I want to show here is the risk condition. One example is that the content of a pointer, pointer outside enclave, can be changed after you check it.
18:51
It's very similar to the file handler risk condition issue in the memory and the disk.
19:02
In enclave development work, developers often need to put in some code into enclave. Then they need to divide the code into trusting part and untrusting part. So in the original code, it might not be a problem, but after pointing, that kind of time of check, time of use issue might happen.
19:29
So please pay attention to the pointers, especially pointer of the pointers, which refer to untrusted part from the trusted part.
19:41
So you better add additional checks for such kind of data referring. If possible, copy the buffer inside enclave instead of just refer to them from a pointer. Okay, so thank you all for your attention. If you have any questions, please feel free to contact me by email.