A Tale of Two Worlds: Assessing the Vulnerability of Enclave Shielding Runtimes
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 | 490 | |
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/47389 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
FOSDEM 2020215 / 490
4
7
9
10
14
15
16
25
26
29
31
33
34
35
37
40
41
42
43
45
46
47
50
51
52
53
54
58
60
64
65
66
67
70
71
72
74
75
76
77
78
82
83
84
86
89
90
93
94
95
96
98
100
101
105
106
109
110
116
118
123
124
130
135
137
141
142
144
146
151
154
157
159
164
166
167
169
172
174
178
182
184
185
186
187
189
190
191
192
193
194
195
200
202
203
204
205
206
207
208
211
212
214
218
222
225
228
230
232
233
235
236
240
242
244
249
250
251
253
254
258
261
262
266
267
268
271
273
274
275
278
280
281
282
283
284
285
286
288
289
290
291
293
295
296
297
298
301
302
303
305
306
307
310
311
315
317
318
319
328
333
350
353
354
356
359
360
361
370
372
373
374
375
379
380
381
383
385
386
387
388
391
393
394
395
397
398
399
401
409
410
411
414
420
421
422
423
424
425
427
429
430
434
438
439
444
449
450
454
457
458
459
460
461
464
465
466
468
469
470
471
472
480
484
486
487
489
490
00:00
Vulnerability (computing)SpacetimeBitUniverse (mathematics)CausalityProjective planeCompass (drafting)Multiplication signVulnerability (computing)Context awarenessGroup actionRun time (program lifecycle phase)Contrast (vision)Computer animation
01:09
System programmingCompilerComputer hardwareStack (abstract data type)Perspective (visual)DisintegrationPrototypeSource codeBefehlsprozessorQuicksortMikroarchitekturSocial classNeuroinformatikLevel (video gaming)CoprocessorNumberVulnerability (computing)InjektivitätStructural loadSystem programmingResultantLine (geometry)Extension (kinesiology)Operating systemLibrary (computing)Connected spaceProjective planeOpen sourceBefehlsprozessorSoftware developerCache (computing)Computer architectureThread (computing)BitSoftwareRight angleWater vaporGoodness of fitLatent heatDifferent (Kate Ryan album)Lie groupReal number40 (number)Instance (computer science)Computer animation
03:23
outputLogic gateRight angleInformation securityPoint (geometry)Cartesian coordinate systemComputer animation
04:01
Computer fontVulnerability (computing)Stack (abstract data type)Range (statistics)Pointer (computer programming)String (computer science)IntegerExecution unitProjective planeInstance (computer science)Software frameworkDifferent (Kate Ryan album)Open sourceNumberPerformance appraisalVulnerability (computing)Computer animation
04:43
Execution unitComputer fontVulnerability (computing)Stack (abstract data type)FrequencyEmbargoSurfaceBefehlsprozessorHard disk driveLine (geometry)FrequencyOperating systemInformation securityVirtual machineLevel (video gaming)Web browserMultiplicationInstance (computer science)Electronic mailing listCodeNeuroinformatikPeripheralOperator (mathematics)Web 2.0Computer animation
06:04
SurfaceComputer hardwareScalable Coherent InterfaceBefehlsprozessorKey (cryptography)Cartesian coordinate systemCuboidInformation securityLine (geometry)System programmingPoint (geometry)SurfaceRight angleWorkstation <Musikinstrument>Game theoryNormal operatorComputer animation
07:28
SurfaceBefehlsprozessorSurfaceSocial classVulnerability (computing)QuicksortBuffer solutionGame theoryPoint (geometry)Right angleBuffer overflowMetropolitan area networkComputer animation
08:00
Smith chartLibrary (computing)Software development kitOpen setTrusted ComputingOpen sourceProjective planeMoment (mathematics)Multiplication signSoftwareDifferent (Kate Ryan album)NumberSystem callAliasingIntelSystem programmingQuicksortECosArithmetic meanCodeIntegrated development environmentLevel (video gaming)Process (computing)Right angle
08:27
Integrated development environmentCoprocessorThermodynamisches SystemBridging (networking)Run time (program lifecycle phase)Integrated development environmentAnalogyCoprocessorCartesian coordinate systemSoftwareBridging (networking)Programming paradigmSoftware frameworkNormal (geometry)System programmingAngleSystem callWater vaporSoftware developerLink (knot theory)Axiom of choiceMultiplication signQuicksortComputer animation
09:47
Run time (program lifecycle phase)Mobile appFormal languageVirtual machineComputer programmingMultitier architectureBridging (networking)SoftwareCuboidDependent and independent variablesQuicksortKey (cryptography)Operator (mathematics)Cartesian coordinate systemMoment (mathematics)Computer programmingPoint (geometry)Computer programmingBitAbstractionPointer (computer programming)Virtual machineSoftware frameworkSystem programmingLibrary (computing)Binary codeNumberLevel (video gaming)Instance (computer science)CompilerOffenes KommunikationssystemProgramming languageFormal languageRight angleField (computer science)PlotterData storage deviceSoftware developerMultilaterationComputer animation
11:46
Multitier architectureMobile appExecution unitGUI widgetBefehlsprozessorRule of inferencePointer (computer programming)Disk read-and-write headReading (process)SurfaceFlagRun time (program lifecycle phase)IntelComplex (psychology)MiniDiscDirection (geometry)String (computer science)Military operationOperations researchRead-only memoryDefault (computer science)Interior (topology)1 (number)Cartesian coordinate systemLevel (video gaming)Presentation of a groupSubsetVulnerability (computing)Formal languageBuffer solutionBitCompilerCASE <Informatik>Functional programmingElement (mathematics)Multiplication signInformation securityPoint (geometry)System programmingConstructor (object-oriented programming)Computer fileState of matterNumberGroup actionInstance (computer science)Right angleSoftware developerOnline helpMessage passingDigital photographyIterationIntegrated development environmentLine (geometry)CompilerStack (abstract data type)Order (biology)Suite (music)Cycle (graph theory)Virtual machineQuicksortKey (cryptography)State observerSurfaceCodeService (economics)Sheaf (mathematics)Dependent and independent variablesWeb pageContrast (vision)Computer programmingSet (mathematics)Complex (psychology)Direction (geometry)BefehlsprozessorString (computer science)Address spaceFlagPointer (computer programming)Software frameworkCoprocessorConfiguration spaceCryptographyMemory managementLoop (music)Heat transferComputer hardwareEncryptionBinary codeOperating systemInverse problemRun time (program lifecycle phase)WritingProgramming paradigmSemiconductor memoryComputer animation
18:44
FlagException handlingCache (computing)BuildingSide channel attackSemiconductor memoryInformationBitReduction of orderRevision controlOperating systemMultitier architectureSurfaceSoftware bugSoftwareVulnerability (computing)Run time (program lifecycle phase)CoprocessorWordSubject indexingOperator (mathematics)Ferry CorstenKey (cryptography)Perspective (visual)Direction (geometry)Level (video gaming)ExplosionMultiplication signEscape characterException handlingRight angleGroup actionWebsiteSystem programmingInstance (computer science)Line (geometry)Goodness of fitComplete metric spaceComputer animation
21:09
Point (geometry)Level (video gaming)Form (programming)BitPointer (computer programming)RootAlpha (investment)Multitier architectureBefehlsprozessorProgram flowchart
21:38
Pointer (computer programming)Menu (computing)Read-only memoryPoint (geometry)Offenes KommunikationssystemVideoconferencingFunctional programmingComputer programmingSemiconductor memoryDeterminismFunction (mathematics)Endliche ModelltheorieLetterpress printingMultiplication signAddress spacePointer (computer programming)SoftwarePrimitive (album)String (computer science)QuicksortComputer virusReading (process)Computer animation
22:52
Pointer (computer programming)Normal (geometry)Open sourceAddress spaceProduct (business)Software bugRun time (program lifecycle phase)System programmingProjective planeCartesian coordinate systemString (computer science)Source codeLibrary (computing)Right angleSource code
23:37
Level (video gaming)String (computer science)Software development kitIntelRead-only memoryComputerFormal verificationConvex hullSemiconductor memoryOracleFormal languageGoodness of fitInformation securityAnalogyWebsiteSoftwareRight angleEntire functionVariable (mathematics)LengthString (computer science)NumberBuffer solutionUniversal product codeSide channel attackMeasurementPointer (computer programming)Multiplication signParameter (computer programming)Run time (program lifecycle phase)NeuroinformatikLie groupPoint (geometry)Link (knot theory)Logic programmingQuicksortExclusive orCASE <Informatik>Data storage deviceMessage passingSource codeComputer animation
26:17
OracleBuildingWeb pageMedianDistribution (mathematics)Level (video gaming)Table (information)System callSeitentabelleComputer animation
26:45
Web pageLoop (music)IterationCodeImage resolutionTemporal logicSeitentabelleWeb pageString (computer science)Multiplication signLengthBitRight angleSeitentabelleLoop (music)Order (biology)Student's t-testArithmetic progressionComputer animation
27:22
Loop (music)IterationInterrupt <Informatik>Table (information)MeasurementSystem callMultiplication signInterrupt <Informatik>Arithmetic meanSoftware frameworkExtension (kinesiology)SeitentabelleCodeProduct (business)Exception handlingDebuggerPrimitive (album)Loop (music)BuildingOpen sourceVideo gameCASE <Informatik>Computer animation
28:09
Kernel (computing)RootWeb pageSpacetimeOpen sourceMappingLibrary (computing)Principle of maximum entropySoftware frameworkEndliche ModelltheorieMetropolitan area networkMultiplication signReduction of orderSpeciesTable (information)Computer animation
28:47
Scalable Coherent InterfaceInterrupt <Informatik>DeterminismOracleBuildingSeitentabelleUniform resource locatorVideo gameElectronic program guideSeitentabelleMultiplication signControl flowSemiconductor memoryRight angleComputer animation
29:15
OracleAdvanced Encryption StandardRead-only memorySteady state (chemistry)Semiconductor memoryRoundness (object)OracleCiphertextKey (cryptography)BitMultiplication signFunction (mathematics)CryptographyInverse elementResultantUniform resource locatorVideoconferencingContent (media)MomentumSound effectPlanningTerm (mathematics)Computer animation
30:30
Advanced Encryption StandardOracleIntegerRange (statistics)SurfaceVulnerability (computing)Pointer (computer programming)String (computer science)Inclusion mapMultiplication sign2 (number)Real-time operating systemKey (cryptography)NumberVulnerability (computing)Formal languageLevel (video gaming)Product (business)System callState observerUniversal product codeSystem programmingBitSet (mathematics)CASE <Informatik>ProteinComputer animation
31:26
AnalogyComputer fileDecision theorySoftware developerSystem programmingBitCodeComputer architectureSource codeThermodynamisches SystemOpen sourceService (economics)Formal languageSoftwareComputing platformArithmetic progressionProcess (computing)Instance (computer science)Bit rateCASE <Informatik>Term (mathematics)Observational studyMereologySakokuCoefficient of determinationSpeciesState of matterRight angleProduct (business)Computer animation
34:37
Binary codeRead-only memorySpacetimeAddress spaceSingle-precision floating-point formatComputer hardwareComputer wormSpacetimeSoftware frameworkShared memoryCodeInterior (topology)Order (biology)View (database)Duality (mathematics)Level (video gaming)1 (number)Product (business)Single-precision floating-point formatVulnerability (computing)Cartesian coordinate systemInstance (computer science)Right angleSoftware developerMobile WebQuicksortDegree (graph theory)Computer animation
36:27
Point cloudFacebookOpen source
Transcript: English(auto-generated)
00:13
The next speaker is John.
00:21
All right, thanks. So what is this all about? In contrast to the previous talk, it's going to be a bit more attack-oriented, so that can also be fun. Let's have a look. So the title actually is based on a movie, A Tale of Two Worlds. And you see I adopted the movie poster a bit.
00:44
And it's going to be about assessing the vulnerability of enclave shielding runtimes. So this is based on an academic paper that we did last year. Actually, it dates back to 2015, even for the first class of books. So it's been a bit of a long-running project together with the people from Birmingham.
01:02
And I am Jo from KU Leuven University. You make this research group. So maybe very briefly, a little bit on the research context. Back in Leuven, we are doing actually what I would call a very broad first approach to trusted computing. So we are looking, I would say, at all levels
01:22
of the system stack involving trusted computing as sort of a red thread throughout the research. We have people looking into low-level processor design, building new open source, just computing architectures like Sankus. It's one of the flagship projects. It's a little 16-bit architecture, 16-bit processor
01:41
with enclave support. It's also completely open source. So if you want to know more, you can talk about this with me later. We also have people looking into compilers, specific operating system extensions to use with trusted computing. And then I think the more interesting line of work that I want to talk about today is more the attack line of work.
02:01
We look at integrated, well, trusted computing integrated by attacks and defenses, sort of like a defender race, z-bars chasing lions, lions chasing zebras. Right? So there's a number of, let's say, more visible high-impact results.
02:21
You might recognize this logo on the left. That's the foreshadow vulnerability that we disclosed in 2018. It's basically a meltdown variant that completely dismantles the jigs. And that's the reason, for instance, you have to flush the cache when you enter a jig. There's also more recent results like the zombie load attack last year and this weird thing here on the right.
02:42
It's called Blundervolt. It's a really cool attack. We use software-based interfaces to undervolt the CPU, inject faults into computations. So a lot of what is here called CPU vulnerability research is new class of processor-level microarchitectural vulnerabilities. There's also a tool that I developed a while ago.
03:02
It's called SGXstep. It's also completely open source. I will talk a bit about it later. And in a way, it's really a convenient library to make all of these attacks easy, sort of a little offensive operating system development project. So let's see how that connects.
03:23
But first, I want to talk a bit higher level. What are enclaves? And enclaves are often compared to fortresses. So I took a nice little picture here of a fortress. You can see it's a very decent fortress, thick walls, impossible to get inside. That's the promise of tourist execution. Well, this is old, right?
03:42
Centuries ago, people figured out if you cannot go through the walls, go through the gates. And Jethro and his talk said already this morning, the interface, that's really where security is interesting. That's the weakest point, typically, in your enclave application. So very simple idea, we're going to ram some enclave gates. Simple idea, high impact.
04:03
So this is from the paper. We did a systematic evaluation. We found over 35 different instances of interface vulnerabilities in enclaves. We systematically systemized them across two tiers. We looked at eight major open source projects. You might recognize some of them here,
04:23
have been talked about earlier. Jethro's framework for Rust. There is Microsoft Open Enclave, the Intel AGX SDK. So we really have a number of highly visible industry projects here, also more research oriented frameworks like the Sankus framework that we developed ourselves.
04:41
It's also fair to say that we had quite some impacts. We got over five, well, we got five CVEs and a very associated long embargo period. So we're happy to now finally talk about this line of work. But again, the bigger picture, why does it matter, right?
05:02
All these embyros and CVEs. No one is using enclaves, you might be thinking. Well, usually when I want to convey the importance of trust execution, I start from this picture. And shouldn't be too new for you. So hardware-based computing bathroom.
05:20
But actually, it's quite ridiculous if we look in a higher level how we have been building secure systems over the last decades. Basically, what we have been doing when you think nowadays of, for instance, a piece of JavaScript code. It executes inside a web browser, which itself is a huge application, which executes on top of an operating system, which might execute inside a virtual machine.
05:42
Executing on top of a CPU, which itself is decomposed of multiple layers of microcode, microarchitecture, silicon, connects with different peripherals and all of that is trusted. All of that is green. That means a single book in any of those lower layers and your security is worthless. It completely collapses.
06:03
In this respect, what trusted computing tries to give you, promises to give you, is this picture. We go from this picture to this picture and it's great. A lot of it is now white. It's basically untrusted. And our security is basically rooted inside the CPU.
06:20
So systems like Intel SGX, in a nutshell, give you isolation and autostation with a cryptographic key that never leaves the CPU. That means that you only trust your end-level application here and your CPU. Great picture, but of course, with security researchers, it's not as easy as it seems. And indeed, since the launch of SGX, we have seen a lot of attacks, a whole line of work,
06:42
basically attacking this little green box here, the CPU, which is not as trustworthy as it seems. I mentioned foreshadow. You have Riddle, Zombiload, Spectre, all of these books that are here to stay, I would say, which show that this green box can still be attacked successfully. And even so, because you control the operating system,
07:02
you can typically do that more efficient and in more creative ways than when you're a normal application-level attacker. Looking at this picture, what we wanted to do in this research is to take a step back and to basically observe that this is not
07:22
the only green box. This is all very cool research, but maybe that's not the easiest way to attack an enclave. What if we just consider that the CPU is trustworthy? Let's say that vendors will get this right at some point. What is the attack surface left? Well, obviously, these are the game books. What about software vulnerabilities
07:40
inside the enclave? And I'm not talking about, let's say, well-known buffer overflows, not the common sort of software vulnerabilities. Are there new classes of software vulnerabilities that are, let's say, particular to enclaves and will occur when entering and exiting this game box? Again, we have seen it today already a number of times.
08:04
There is an explosion at the moment in the open source ecosystem around projects like Intel SGX, but not only Intel SGX, many different SDKs, many different trusted software layers. And we want to look what are the common goals
08:21
of these frameworks, and what does that mean for an attacker? If you look at a very high level, all of these frameworks basically allow you to execute a piece of code, piece of application code, in the secure world, also called an enclave, which is rooted inside the processor and executes basically in a containing
08:42
untrusted environment. You can compare it to a hostile desert and a small little secure oasis. That is basically SGX. Just as with an oasis, you can imagine that the trickiness is how do you transfer from this desert, hostile environment
09:01
into the oasis and back. Particularly, what we want, ultimately, is to give a convenient programming model to our application developers, our enclave developers, just compile their code as if it executes on a normal CPU, compile it to a standard compiler,
09:21
and you link it to what we call a trusted runtime, which basically will make a bridge from the hostile environment, the desert, to the enclave and back. So we want to make a piece of software which is trusted, sits here in the middle, and will mediate
09:41
between the untrusted world and the trusted world, the tale of the world's analogy. Beautiful picture again. Our problem is solved. We make a little bridge. We go from the desert to the oasis and back. But of course, what happens when your bridge is flawed? Then things become really, really bad.
10:02
And that's what we did. So the key lessons we want to draw from that is what are the responsibilities of this opaque yellow box? We have some sanitization layer, some software which is maybe comparable to an operating system. Some people call this also library operating system.
10:21
A bit more about that later. But sort of sits in between. And what does it have to do? At what point can we call it to sort? What are the responsibilities? To answer that question, we start by building a more systematic way of looking at that. We split that into three tiers,
10:41
where tier three is basically the application developed by the actual application developer, the end user. And tier one and tier two are respectively what we call the ABI, Application Binary Interface. People who have some compiler expertise will recognize that. And API, Application Programming Interface,
11:00
which basically sanitizes the way you plug in your end user application. So very high level. What we want to do is to run this application in a higher level programming language. Could be C, but could also be Rust or any other language. And then we want to basically transfer from a moment where the machine is entirely controlled by the attacker.
11:22
CPU registers, all of it. You will have to execute a little piece of assembly, which sort of builds up the first abstraction layer being typically C. Could also be Rust, for instance. And then you will do a number of sanitizations, which are already visible at the programming level, and things like pointers and the like.
11:40
And then you switch to the application. So we have a framework now to reason about this. What I'm going to do in the rest of the presentation is to present a subset of those 35 vulnerabilities. The ones that I feel are more interesting, first on this ABI level, and then on the API level. And the application is basically out of scope.
12:01
But obviously, things can go wrong there as well. This would be the buffer overflows I was talking about if you have an unsafe language like C. So what is this ABI about? As I said before, the key sort of thing you need to keep in mind is that when you enter an enclave, you are sharing the same CPU with a hostile environment.
12:23
So when you enter, the CPU is entirely controlled by the attacker. And all of the registers, for instance, could be poisoned. It could contain poisonous values. And this is in sharp contrast to sort of an implicit assumption by the compiler. However, nowadays, our current compilers have been built with the assumption
12:42
that the machine they're running on can be trusted. So typically, a program is spawned by, for instance, an operating system. And it's considered that this operating system is not trying to attack your application, obviously. So that means that we will have to do that manually. We will have to write a piece of assembly which
13:00
will sort of transfer the CPU from an insecure state to a state which we call secure, which is basically the assumptions by the compiler which luckily have been documented in the application binary interface. This also happens when you link two files together from different developers. So compilers need to be very explicit about the assumptions they make.
13:22
So we can just read a document and make sure we meet all of those assumptions. For instance, a stack pointer is something you might be familiar with as well. So the high-level message here is that this is relatively well understood. But it makes sense in order to make your program
13:41
just function you already need to think about this. This goes back a long way to early compilers. So we found that this requirement is not completely overlooked. However, as an often with security, the edge cases. That's where it goes wrong. So here you have a bit of an overview.
14:04
There is a number of vulnerabilities related to stack pointers, also to basically just forgetting to clear the edges on the way out. The way out, you have the inverse problem. You want to transfer from a trusted machine state to an interested desert, hostile world. And you need to make sure, of course,
14:21
to cleanse all remaining secrets from registers. But more interestingly is this status flag. And that relates actually to a more high-level observation we made. And that's what I want to talk about. Namely, the attack surface at the ABI level seems to be very noticeably bigger
14:42
on this line of highlighted SDKs, which are basically Intel SGX SDKs that run on a very complex Intel x86 CPU. And these two ones are research frameworks that are basically built on more risk-like CPUs. And the main message here is the more complex your underlying architecture, the more attack surface
15:02
you will have associated. It's not the first time this has been noticed. This is, again, a big, big downside of x86. And what do I mean? Let's have a look at one of those very complex behaviors of Intel x86.
15:22
For instance, so the typical for those that are not entirely familiar with CISC, which is complex instruction set programming and risk-reduced instruction set programming. The philosophy of a complex instruction set is to add new instructions for features you think might be useful.
15:41
So that's why the Intel SDM is so many pages. They have hundreds and hundreds of instructions. And one of those, for instance, is related to this sort of programming paradigm, which is indeed very common. I call it here a memset. You go with a for loop over an array, and you sequentially access the elements, in this case, to store the value 0 in there.
16:04
You could write an x86 very efficiently as follows. You have first a number of initializers, and then you have this highlighted instruction, which is a repeat string instruction. And this repeat here basically acts as a hardware level for loop. This entire for loop can be encoded in one instruction,
16:20
which basically will go through your array and repeatedly move a pointer from left to right, from low to high addresses, every iteration of this for loop, and then store the value 0. So that's quite neat, you might think. But then also, for whatever reason, they thought, let's make it a little bit more complex.
16:41
Maybe in some cases, you don't want to traverse this array from left to right, but from right to left, from high to low addresses. Again, for whatever reason, that's supported. And that's actually supported with this r flags, e flags register. So if you write a 1 to the direction flag bit in the r flags register, the f bit,
17:00
then this instruction will behave entirely differently. So one bit in a configuration register, and this thing goes from right to left. What could go wrong? We start reading the API. This is a relevant section here, and it very clearly says, because of course,
17:21
compilers want to optimize a bit, and compilers don't want to explicitly set these bits every time they do a repeat string instruction that would be opposed to the purpose of this instruction being very fast. So they say, let's assume no one really uses this from right to left. We always use this from left to right anyway. So let's assume it's set to left to right.
17:40
If you want to use it from right to left, you have to set it first. We don't function entry. We assume it's set in the normal direction, left to right. OK, so let's put this piece of code in an enclave. Very common programming paradigm. This is verbatim from one of the functions in the Intel SDK. You allocate a buffer on the enclave heap
18:00
to set memory here. And then you go through this buffer. From left to right, you initialize it. All fine. If this user here puts on a black hat, becomes malicious, what can go wrong? First thing you want to try, of course, is to flip these bits. So just you control the processor. Just before you enter, it's like a one-line patch in the Intel SDK in the interest of run time.
18:22
You put this to one. You enter. It allocates the buffer on the heap. So far, so good. But then of course, it goes wrong, and it will write heap corruption from right to left. And imagine that this piece of heap you just created is neighboring a crypto key. Now you've just overwritten the crypto key with zeros, which basically is a dummy encryption.
18:42
This is a really severe thing. Intel assigned a CVE for this. They assigned its criticality high, which is actually interesting. I think meltdown had been assigned medium. This is high. And then they arrived, and this is interesting. This potential vulnerability is present
19:00
in all SGX enclaves built with the affected versions of the SDK. And this shows the importance of looking for vulnerabilities in the trusted runtime. You find one vulnerability in the trusted runtime. All software is affected. It's like a bug in the operating system. There is actually more.
19:22
We'll maybe just go on the high level. So this DF, this direction flag, is really the most severe one. But there is also this AC flag, for instance, which is really interesting, at least from an academic perspective. So AC stands for alignment check. And again, Intel X86 processors do not have any restrictions on alignment. You can do unaligned accesses.
19:40
They might be a bit slower, but they support it. But then again, for whatever reason, they say, you can also optionally force the processor into checking alignment. So let's force the processor into checking alignment. And we're going to try to use it as a side channel. So we're not going to make memory corruption this time. We're just going to try to learn something about what the enclave is doing.
20:01
So I made a very simple enclave here, which just accesses A, B, C, or D. So it will access two bytes, A or B, B or C or C or D, depending on the index you're going in. Let's say this could be an S-box, and this index could be related to the secret key. So first, we enter it without alignment checks. It just accesses AB.
20:21
We are all good. And then we enter it with alignment checks. And it's going to access BC, which is an unaligned 16-bit word. So it's a 16-bit word with a lower two bits than 0 in the address. So it will generate an alignment check exception, which exits the enclave and basically notifies your operating system, hey, there is an unaligned access going on. And that gives us at least one bit of information.
20:41
We know the enclave performed an unaligned access. It's completely unnecessary because the software could have cleared these bits on entry and didn't. So now current versions also do that to at least reduce side channel attack surface. The cool thing is that you can do this really
21:00
on a very, very fine-grained granularity. So it's better than all the other known side channels in this respect. But let's look a bit more at the second tier. And so the first tier was basically all these cool tricks
21:21
you do with CPU registers. And this is more high level. Let's do some tricks. There are other API level using things like pointers that if you program a bit with C or alpha million root. So this is less magic, hopefully, but more intuition. First, very, very simple enclave program.
21:41
It's called echo. And it will just run echo. So you basically call the main function, the e-call entry point. And you say, here's a string, hello world. And it resides in the untruth address space. So enclaves in SGX, but in many enclave programming models, can just access the unprotected memory. So you put a string here, ready, hello world.
22:02
And it will access that. It will read that and dump it on the output. Just a very simple dummy example. Again, what could go wrong? Well, let's say that our enclave actually is a useful enclave. And it contains a secret. The secret is top secret. And we just flip this pointer. So we give a pointer to the string hello.
22:22
Hello is unprotected and known. It's a public piece of data. And it will print the public piece of data. If we just flip the pointer, and we give a pointer to the secret piece of data, this stupid dummy enclave will just print top secret. So you can just print whatever you want. You have a sort of arbitrary read primitive in the enclave,
22:42
because the software will print whatever you give it a pointer to. You give a pointer to a secret, it will print a secret. You might think this is artificial. This doesn't happen, right? This is really stupid. Well, here's a little video of the graphene SGX system, where we found exactly this book. So we're going to run a normal Linux application.
23:01
And then we're going to link it to this graphene library operating system. Now we started up. And this is the untrusted runtime. I just entered the address of the secret I wanted to print. And now you see here, super secret enclave string. So this actually works, right? And we were like, whoa, that's cool. How do you protect against that?
23:21
And this graphene grants that this is a research project. I think it's really cool that they made the source code open source available. It's understandable there are a few of those, let's say, hiccups, bugs in there. So we turn our attention to production software, right? Intel SGX SDK. One analogy here.
23:41
Why a picture of this guy? Well, this is called in security research confused deputy attacks. This guy is a deputy. That's the enclave. He holds a gun. He has the permissions on enclave memory. And you just give him a bullet, and he will shoot himself in the foot. That's the idea. You abuse that the software has access rights to enclave memory and exposes you with an oracle
24:02
to let it do what you want. So we turn our attention to SGX Intel software. So this is really production code. They, of course, do check that. And you have the hello world. And it will check that the hello world buffer lies outside the enclave. How does it do that?
24:21
It's a string buffer. You first need the length. So you just compute the length of the string s here, this argument. You store it in a local variable. And then you check whether the entire string from start to end lies outside. So there's a number of things that can go wrong here. But this is actually sound logic. You compute the length of the string.
24:42
You check that the entire string start to end lies outside. What could go wrong? Let's swap the pointer and just try what goes on. If I give a pointer to, for instance, this secret here, which is inside the enclave, step one is it will dereference whatever pointer I give it, lies inside the enclave.
25:02
And it will do a computation, a string length computation. So it will, in my case, if I pass secret one, it will advance one byte. And then it sees a zero. A null term, there's a string in C. And then it will say, ah, the length is one. If I would have given it secret two, it would just have string length is zero. So we already see that there is some dependency.
25:22
That's maybe interesting to keep in mind. But then secondly, the attack didn't succeed because it will see, oh, S plus one lies inside the enclave. And it will say illegal argument. So what can we still do? This is where side channels kick in, right? Side channels are really cool. So it says you cannot access it.
25:41
But actually, if we are really attentive, it will say, when you enter it with secret one, it will tell you, I have to go one byte ahead. And then say, ah, no, you cannot access it. If I enter it with secret two, it will say immediately, ah, no, that's the end of the string. And you cannot access it. So the timing, the time it needs here
26:01
to determine whether you can access it or not will depend on your secret. And that's a side channel, right? So we just need to measure execution time of this thing here. And we learn whether or not a certain byte in the enclave is zero or not, right? That's the idea. Let's see if that works, right? We just measure the execution time.
26:20
Ah, damn, quite some noise. People already said today entering and exiting of enclaves is really involved. There is a lot of things going on, including microcode. So this is not very useful. This is already the median of 100,000 runs. Well, the distribution of 100,000 runs, and you don't really see anything happening here. So that doesn't work. But maybe some of you know that you can also
26:42
do things with pagefolds because we control page tables. So let's try to do that. Intel says you can see accesses at a page-level granularity. So we set out, and we said, OK. Let's think a bit if we can do something with page tables. You have this for loop here, string length. You have your data here. But it turns out that you're a bit in a catch-22.
27:03
In order to make progress, you need to have both pages mapped in. If you revoke access rights here, then you will see that string length is being called. But it will also, and then you want it to continue, so you're mapping the page again. You also have to map in this page. And by the time that you see the access, it has already been completed. So that doesn't work.
27:26
So we're going to use interrupts. And the basic idea is this AGX step framework I talked about. So we're going to execute our enclave exactly one instruction at a time. And then we execute our attacker code. We do some measurements in the page tables or other means.
27:41
And then we're going to resume the enclave. We're going to do this in a loop. Now, this sounds like a debugger, right? You just debug your enclave. Of course, this is not going to work, because the debugger exception is being blocked for production enclave. So we need another debugging primitive. And we're going to use that. We're going to make that using timer interrupts. So we can just configure the timer very precisely
28:01
to interrupt right after this instruction, do our attacker code, and then configure it again to interrupt right after the next instruction. Sounds quite crazy, but actually this works. And it's really involved. If you want to talk about this, I would be very happy to come talk after me. It's an open source framework on GitHub. And people are actually using this, so I'm very excited.
28:23
And it's actually quite neat. So we use the dev mem mappings of Linux on an unmodified kernel. And then with root access, of course, we map that into user space. We can manipulate APIC timers, page tables, all of it. And we basically build our own little offensive kernel
28:42
as a library in user space. So now we have a primitive to execute this very precisely, one instruction at a time. And then we just look. And every time, we can also look in the page tables whether the enclave has accessed a certain location or not. And with that, basically, we can reconstruct
29:01
all the zero bytes. So that's great, right? We have a primitive to distinguish all the zero bytes in enclave memory. It sounds cool, and it was a lot of work, but then what do we do with that? And also, just to give you some idea, you can completely break AES with that. And that's what we did together with the people in Birmingham.
29:20
So we interrupt our victim. We made a pool of concept victim enclave. We interrupt it right between the last bit one round. So before the last round of AES, we interrupt it. As a result, it will write the secret key in enclave memory. And I'm just going to do that many times until my secret key contains a zero byte,
29:42
chosen plaintext attack. And then basically, what I'm going to do is to enter on a new thread, probe whether this byte is zero or not. I just built a deterministic oracle to do that with a ZX step. And then what you have, and I'm going to spare you all the crypto details, but it's actually very simple.
30:01
You know that this was zero. You let the enclave compute again in the final round. Now you know that what is the output of the ciphertext. And then you can just vectorize the ciphertext. Because you know this is zero, we can do an inverse S-box lookup. This gives us one byte of the round key. We do that many times until we have all the bytes of the round key. If you just give them random plaintext,
30:21
it will randomly have zero bytes in the locations. We have all the bytes of the final round key, and we get a full long-term AES key, right? So that's cool. Complicated attack, you might think, but this is real time. So it's now compiling, it's running, and it has a AES key. With sgxstep and everything in between. So this is actually really practical.
30:41
Just took us 30 seconds to get an AES key. So a bit of a bigger picture. I will not go in detail for all of the vulnerabilities. I can refer you to the paper to read more about it, of course. So maybe one, let's say, high-level observation
31:02
is that we found these books both in production code and research code. Also, we found them in production level SDKs as well as in research, but also with unsafe languages like C and also safe languages, especially then the ABI-like host.
31:20
There's also a number of things related to system calls here that you have to watch out for, and basically operating system is now interested. The conclusion should be wash your hands before you enter the enclave. Always do proper sanitization of your ABI and API. Sounds simple, but really goes wrong very easily. Also, let's say,
31:42
a bit more long-term lessons for the community, I think, is many of those things, we have seen them before in operating system development. I think as a trust execution community, we should really try to draw lessons from that and to attempt to not make the same mistakes again. As a final note, you can also find all of the source code here.
32:01
As always, we met the attack code open source. I think that concludes the talk so far. Jethro, you mean a trust execution platform
32:32
or a software SDK? Or both. For software SDKs,
32:42
as we also say in the paper, having a safe language really, really helps. For instance, the Rust platform, it's really a big step forward there. And then you basically can reduce your attack service at least to the ABI, which is more manageable. It's also something that end developers don't really have to worry about if we just vet that thoroughly.
33:01
Regarding TE platforms, I think it's even fair to say that I think we need more research on that. I think maybe these things are not as production ready as they are being sold by certain process of companies. I think we are really making progress there.
33:20
And for instance, one of the things I also usually say is that SGX as an architecture has never been broken. The design is really solid. All these books are micro architectural books, which means that maybe the biggest intricacy is that they built SGX on top of x86. And that is, I think, a lesson. We need to build open source,
33:42
risk-based, just execution environments. And I'm very glad that people like, for instance, people from Berkeley with Keystone are starting to do that.
34:27
So the question is, how does this generalize to Tucson? So very short answer, maybe with a graphic.
34:41
You are completely right. That's what we call in the paper single outer space TE designs where the enclave lives in the shared outer space are more vulnerable to many of those attacks, especially the API level attacks. However, even Tucson, to a certain degree, is affected by this. And there is CVEs from prior researchers that actually showed it. And you see, for instance,
35:00
this what we call dual world view where they don't share the outer space explicitly. It's the design of Tucson and also other TEs. But you typically still have a region of shared memory which you explicitly map in both worlds in order to do efficient IO. And this is, again, a trade-off between efficiency and security, maybe. But you can still do many of those attacks
35:21
even on Tucson. Yes?
35:42
As an application developer, maybe your biggest concern should be choosing a right framework. For instance, realizing that some of these frameworks are research code. I really hope that some of those are not being used in production. And including the ones on...
36:01
We ourselves, in Leuven, developed this Sankus framework. And it's really cool. I really like it. But I hope no one uses it because it's really not meant to be production quality. It's often like that in software vulnerability research. I think it will move more mature.