0:00:00.000,0:00:10.667 rc3 preroll music 0:00:12.235,0:00:17.520 Herald: So for the next talk, I have Jo[br]Van Bulck, and Fritz Alder from the 0:00:17.520,0:00:24.640 University of Leuven in Belgium, and David[br]Oswald professor for cyber security in 0:00:24.640,0:00:29.840 Birmingham. They are here to talk about[br]the trusted execution environment. You 0:00:29.840,0:00:36.320 probably know from Intel and so on, and[br]you should probably not trust it all the 0:00:36.320,0:00:42.160 way because it's software and it has its[br]flaws. And so they're talking about 0:00:42.160,0:00:47.680 ramming enclave gates, which is always[br]good, a systematic vulnerability 0:00:47.680,0:00:52.080 assessment of TEE shielding runtimes.[br]Please go on with your talk. 0:00:52.080,0:00:58.690 Jo van Bulck: Hi, everyone. Welcome to our[br]talk. So I'm Jo, former imec-DistriNet 0:00:58.690,0:01:02.640 research group at KU Leuven. And[br]today joining me are Fritz, also from 0:01:02.640,0:01:06.800 Leuven and David from the University of[br]Birmingham. And we have this very exciting 0:01:06.800,0:01:11.440 topic to talk about, ramming enclave[br]gates. But before we dive into that, I 0:01:11.440,0:01:16.400 think most of you will not know what are[br]enclave's, let alone what are these TEEs. 0:01:16.400,0:01:23.520 So let me first start with some analogy.[br]So enclave's are essentially a sort of a 0:01:23.520,0:01:29.520 secure fortress in the processor, in the[br]CPU. And so it's an encrypted memory 0:01:29.520,0:01:36.960 region that is exclusively accessible from[br]the inside. And what we know from the last 0:01:36.960,0:01:41.560 history of fortress attacks and defenses,[br]of course, is that when you cannot take a 0:01:41.560,0:01:46.560 fortress because the walls are high and[br]strong, you typically aim for the gates, 0:01:46.560,0:01:51.280 right? That's the weakest point in any in[br]any fortress defense. And that's exactly 0:01:51.280,0:01:57.440 the idea of this research. So it turns out[br]to apply to enclave's as well. And we have 0:01:57.440,0:02:01.520 been ramming the enclave gates. We have[br]been attacking the input/output interface 0:02:01.520,0:02:07.600 of the enclave. So a very simple idea, but[br]very drastic consequences I dare to say. 0:02:07.600,0:02:14.640 So this is sort of the summary of our[br]research. With over 40 interface 0:02:14.640,0:02:20.480 sanitization vulnerabilities that we found[br]in over 8 widely used open source enclave 0:02:20.480,0:02:27.040 projects. So we will go a bit into detail[br]over that in the rest of the slides. Also, 0:02:27.040,0:02:32.400 a nice thing to say here is that this[br]resulted in two academic papers to date, 0:02:32.400,0:02:38.880 over 7 CVEs and altogether quite some[br]responsible disclosure, lengthy embargo 0:02:38.880,0:02:46.095 periods.[br]David Oswald: OK, so, uh, I guess we 0:02:46.095,0:02:55.197 should talk about why we need such enclave[br]fortresses anyway. So if you look at a 0:02:55.197,0:03:00.230 traditional kind of like operating system[br]or computer architecture, you have a very 0:03:00.230,0:03:06.131 large trusted computing base. So you, for[br]instance, on the laptop that you most 0:03:06.131,0:03:12.265 likely use to watch this talk, you[br]trust the kernel, you trust maybe a 0:03:12.265,0:03:16.909 hypervisor if you have and the whole[br]hardware under the systems: a CPU, 0:03:16.909,0:03:23.116 memory, maybe hard drive, a trusted[br]platform module and the like. So actually 0:03:23.116,0:03:28.830 the problem is here with such a large TCB,[br]trusted computing base, you can also have 0:03:28.830,0:03:35.521 vulnerabilities basically everywhere. And[br]also malware hiding in all these parts. So 0:03:35.521,0:03:41.951 the idea of this enclaved execution is as[br]we find, for instance, in Intel SGX, which 0:03:41.951,0:03:48.406 is built into most recent Intel[br]processors, is that you take most of the 0:03:48.406,0:03:54.078 software stack between an actual[br]application, here the enclave app and the 0:03:54.078,0:04:01.005 actual CPU out of the TCB. So now you only[br]trust really the CPU and of course, you 0:04:01.005,0:04:05.148 trust your own code, but you don't have to[br]trust the OS anymore. And SGX, for 0:04:05.148,0:04:10.049 instance, promises to protect against an[br]attacker who has achieved root in the 0:04:10.049,0:04:14.694 operating system. And even depending on[br]who you ask against, for instance, a 0:04:14.694,0:04:20.864 malicious cloud provider. So imagine you[br]run your application on the cloud and then 0:04:20.864,0:04:26.724 you can still run your code in a trusted[br]way with hardware level isolation. And you 0:04:26.724,0:04:30.754 have attestation and so on. And you don't[br]no longer really have to trust even the 0:04:30.754,0:04:40.503 administrator. So the problem is, of[br]course, that attack surface remains, so 0:04:40.503,0:04:47.378 previous attacks and some of them, I think[br]will also be presented at this remote 0:04:47.378,0:04:52.395 Congress this year, have targeted[br]vulnerabilities in the microarchitecture 0:04:52.395,0:04:58.589 of the CPU. So you are hacking basically[br]the hardware level. So you had foreshadow, 0:04:58.589,0:05:05.711 you had microarchitectural data sampling,[br]spectre and LVI and the like. But what 0:05:05.711,0:05:10.182 less attention has been paid to and what[br]we'll talk about more in this presentation 0:05:10.182,0:05:17.028 is the software level inside the enclave,[br]which I hinted at, that there is some 0:05:17.028,0:05:22.360 software that you trust. But now we'll[br]look in more detail into what actually is 0:05:22.360,0:05:30.300 in such an enclave. Now from the[br]software side. So can an attacker exploit 0:05:30.300,0:05:34.304 any classical software vulnerabilities in[br]the enclave? 0:05:35.520,0:05:40.880 Jo: Yes David, that's quite an interesting[br]approach, right? Let's aim for the 0:05:40.880,0:05:45.200 software. So we have to understand what is[br]the software landscape out there for these 0:05:45.200,0:05:49.760 SGX enclaves and TEEs in general. So[br]that's what we did. We started with an 0:05:49.760,0:05:53.760 analysis and you see some screenshots[br]here. This is actually a growing open 0:05:53.760,0:05:58.960 source ecosystem. Many, many of these[br]runtimes, library operating systems, SDKs. 0:05:58.960,0:06:03.760 And before we dive into the details, I[br]want to stand still with what is the 0:06:03.760,0:06:09.760 common factor that all of them share,[br]right? What is kind of the idea of these 0:06:09.760,0:06:17.040 enclave development environments? So here,[br]what any TEE, trusted execution 0:06:17.040,0:06:22.400 environment gives you is this notion of a[br]secure enclave oasis in a hostile 0:06:22.400,0:06:27.200 environment. And you can do secure[br]computations in the green box while the 0:06:27.200,0:06:33.440 outside world is burning. As with any[br]defense mechanism, as I said earlier, the 0:06:33.440,0:06:37.680 devil is in the details and typically at[br]the gate, right? So how do you mediate 0:06:37.680,0:06:42.880 between that untrusted world where the[br]desert is on fire, and the secure oasis in 0:06:42.880,0:06:48.480 the enclave? And the intuition here is[br]that you need some sort of intermediary 0:06:48.480,0:06:53.040 software layer, what we call a shielding[br]runtime. So it kind of makes a secure 0:06:53.040,0:06:57.760 bridge to go from the untrusted world to[br]the enclave and back. And that's what we 0:06:57.760,0:07:03.680 are interested in. To see, what kind of[br]security checks you need to do there. So 0:07:03.680,0:07:07.680 it's quite a beautiful picture you have on[br]the right, the fertile enclave and on the 0:07:07.680,0:07:13.680 left the hostile desert. And we make this[br]secure bridge in between. And what we are 0:07:13.680,0:07:19.520 interested in is what if it goes wrong?[br]What if your bridge itself is flawed? So 0:07:19.520,0:07:25.600 to answer that question, we look at that[br]yellow box and we ask what kind of 0:07:25.600,0:07:30.400 sanitization, what kind of security checks[br]do you need to apply when you go from the 0:07:30.400,0:07:35.360 outside to the inside and back from the[br]inside to the outside. And one of the key 0:07:35.360,0:07:38.960 contributions that we have built up in the[br]past two years of this research, I think, 0:07:38.960,0:07:45.920 is that that yellow box can be subdivided[br]into 2 smaller subsequent layers. And the 0:07:45.920,0:07:51.440 first one is this ABI, application binary[br]interface, very low level CPU state. And 0:07:51.440,0:07:54.640 the second one is what we call API,[br]application programing interface. So 0:07:54.640,0:07:58.160 that's the kind of state that is already[br]visible at the programing language. In the 0:07:58.160,0:08:02.400 remainder of the presentation, we will[br]kind of guide you through some relevant 0:08:02.400,0:08:06.080 vulnerabilities on both these layers to[br]give you an understanding of what this 0:08:06.080,0:08:11.760 means. So first, Fritz will guide you to[br]the exciting low level landscape of the 0:08:11.760,0:08:15.440 ABI.[br]Fritz: Yeah, exactly. And Jo, you just 0:08:15.440,0:08:21.840 said it's the CPU state and it's the[br]application binary interface. But let's 0:08:21.840,0:08:27.200 take a look at what this means, actually.[br]So it means basically that the attacker 0:08:27.200,0:08:39.348 controls the CPU register contents and[br]that... On every enclave entry and every 0:08:39.348,0:08:46.480 enclave exit, we need to perform some[br]tasks. So that's the enclave and the 0:08:46.480,0:08:56.560 trusted runtime have some like, well[br]initialized CPU state and the compiler can 0:08:56.560,0:09:03.360 work with the calling conventions that it[br]expects. So these are basically the key 0:09:03.360,0:09:09.120 part. We need to initialize the CPU[br]registers when entering the enclave and 0:09:09.120,0:09:15.520 scrubbing them when we exiting the[br]enclave. So we can't just assume anything 0:09:15.520,0:09:20.960 that the attacker gives us as a given. We[br]have to initialize it to something proper. 0:09:20.960,0:09:30.320 And we looked at multiple TEE runtimes and[br]multiple TEEs and we found a lot of 0:09:30.320,0:09:37.840 vulnerabilities in this ABI layer. And one[br]key insight of this analysis is basically 0:09:37.840,0:09:45.120 that a lot of these vulnerabilities happen[br]on complex instruction set processors, so 0:09:45.120,0:09:51.760 on CISC processors and basically on the[br]Intel SGX TEE. We also looked at some RISC 0:09:51.760,0:09:57.840 processors and of course, it's not[br]representative, but it's like immediately 0:09:57.840,0:10:06.000 visible that the complex x86 ABI seems to[br]be... have a way higher, larger attack 0:10:06.000,0:10:13.760 surface than the simpler RISC designs. So[br]let's take a look at one example of this 0:10:13.760,0:10:20.080 more complex design. So, for example,[br]there's the x86 string instructions that 0:10:20.080,0:10:26.800 are controlled by the direction flag. So[br]there's a special x86 rep instruction that 0:10:26.800,0:10:33.200 basically allows you to perform streamed[br]memory operations. So if you do a memset 0:10:33.200,0:10:40.960 on a buffer, this will be compiled to the[br]rep string operation instruction. And the 0:10:40.960,0:10:50.720 idea here is basically that the buffer is[br]read from left to right and written over 0:10:50.720,0:10:56.880 it by memset. But this direction flag also[br]allows you to go through it from right to 0:10:56.880,0:11:03.200 left. So backwards. Let's not think about[br]why this was a good idea or why this is 0:11:03.200,0:11:08.720 needed. But definitely it is possible to[br]just set the direction flag to one and run 0:11:08.720,0:11:16.000 this buffer backwards. And what we found[br]out is that the System-V ABI actually says 0:11:16.000,0:11:21.120 that this must be clear or set to[br]forward on function entry and return. 0:11:21.120,0:11:26.880 And that compilers expect this to happen.[br]So let's take a look at this when we do 0:11:26.880,0:11:33.840 this in our enclave. So in our enclave,[br]when we, in our trusted application, 0:11:33.840,0:11:39.680 perform this memset on our buffer, on[br]normal entry with the normal direction 0:11:39.680,0:11:45.040 flag this just means that we walk this[br]buffer from front to back. So you can see 0:11:45.040,0:11:51.680 here it just runs correctly from front to[br]back. But now, if the attacker enters the 0:11:51.680,0:11:58.880 enclave with the direction flag set to 1[br]so set to run backwards, this now means 0:11:58.880,0:12:05.840 that from the start of our buffer. So from[br]where the pointer points right now, you 0:12:05.840,0:12:10.640 can now see it actually runs backwards. So[br]that's a problem. And that's definitely 0:12:10.640,0:12:16.193 something that we don't want in our[br]trusted applications because, well, as you 0:12:16.193,0:12:22.880 can think, it allows you to overwrite keys[br]that are in the memory location that you 0:12:22.880,0:12:27.280 can go backwards. It allows you to read[br]out things, that's definitely not 0:12:27.280,0:12:32.960 something that is useful. And when we[br]reported this, this actually got a nice 0:12:32.960,0:12:38.960 CVE assigned with the base score High, as[br]you can see here on the next slide. And 0:12:38.960,0:12:46.800 while you may say, OK, well, that's one[br]instance. And you just have to think of 0:12:46.800,0:12:54.400 all the flags to sanitize and all the[br]flags to check. But wait, of course, 0:12:54.400,0:13:02.960 there's always more, right? So as we found[br]out, there's actually the floating point 0:13:02.960,0:13:07.440 unit, which comes with a like, whole lot[br]of other registers and a whole lot of 0:13:07.440,0:13:17.040 other things to exploit. And I will spare[br]you all the details. But just for this 0:13:17.040,0:13:25.704 presentation, just know that there is an[br]older x87 FPU and a new SSE that does 0:13:25.704,0:13:31.920 vector floating point operations. So[br]there's the FPU control word and the MXCSR 0:13:31.920,0:13:39.849 register for these newer instructions. And[br]this x87 FPU is older, but it's still used 0:13:39.849,0:13:45.680 for example, for extended precision, like[br]long double variables. So old and new 0:13:45.680,0:13:49.120 doesn't really apply here because both are[br]still relevant. And that's kind of the 0:13:49.120,0:13:58.160 thing with x86 and x87 here. That old[br]archaic things that you could say are 0:13:58.160,0:14:03.280 outdated, are still relevant or are still[br]used nowadays. And again, if you look at 0:14:03.280,0:14:09.200 the System-V ABI now, we saw that these[br]control bits are callee-saved. So they are 0:14:09.200,0:14:13.680 preserved across function calls. And the[br]idea here is which to some degree holds 0:14:13.680,0:14:22.400 merit, is that these are some global[br]states that you can set and they are all 0:14:22.400,0:14:27.680 transferred within one application. So one[br]application can set some global state and 0:14:27.680,0:14:35.280 keep the state across all its usage. But[br]the problem here as you can see here is 0:14:35.280,0:14:39.760 our application or enclave is basically[br]one application, and we don't want our 0:14:39.760,0:14:44.480 attacker to have control over the global[br]state within our trusted application, 0:14:44.480,0:14:52.502 right? So what happens if FPU settings are[br]preserved across calls? Well, on a normal, 0:14:52.502,0:14:57.760 for a normal user, let's say we just do[br]some calculation inside the enclave. Like 0:14:57.760,0:15:03.280 2.1 times 3.4, which just nicely[br]calculates to a 7.14, a long double. 0:15:03.280,0:15:09.680 That's nice, right? But what happens if[br]the attacker now enters the enclave with 0:15:09.680,0:15:15.680 some corrupt precision and rounding modes[br]for the FPU? Well, then we actually get 0:15:15.680,0:15:21.520 another result. So we get distorted[br]results with a lower precision and a 0:15:21.520,0:15:26.400 different rounding mode. So actually it's[br]rounding down here, whenever it exceeds 0:15:26.400,0:15:31.280 the precision. And this is something we[br]don't want, right? So this is something 0:15:31.280,0:15:38.240 where the developer expects a certain[br]precision or long double precision, but 0:15:38.240,0:15:43.840 the attacker could actually just reduce it[br]to a very short position. And we reported 0:15:43.840,0:15:49.760 this and we actually found this issue also[br]in Microsoft OpenEnclave. That's why it's 0:15:49.760,0:15:55.600 marked as not exploitable here. But what[br]we found interesting is that the Intel SGX 0:15:55.600,0:16:01.200 SDK, which was vulnerable, patched this[br]with some xrstore instruction, which 0:16:01.200,0:16:10.400 completely restores the extended state to[br]a known value, while OpenEnclave only 0:16:10.400,0:16:16.320 restored the specific register that was[br]affected, the ldmxcsr instruction. And 0:16:16.320,0:16:19.600 so let's just skip over the next few[br]slides here, because I just want to give 0:16:19.600,0:16:27.120 you the idea that this was not enough. So[br]we found out that even if you restored 0:16:27.120,0:16:32.640 this specific register, there's still[br]another data register that you can just 0:16:32.640,0:16:40.000 mark as in use before entering the enclave[br]and with which the attacker can make that 0:16:40.000,0:16:45.600 any floating point calculation results in[br]a not a number. And this is silent, so 0:16:45.600,0:16:50.080 this is not programing language specific,[br]this is not developer specific. This is a 0:16:50.080,0:16:55.840 silent ABI issue that the calculations are[br]just not a number. So we also reported 0:16:55.840,0:17:03.600 this. And now, thankfully, all enclave[br]runtimes use this full xrstor instruction 0:17:03.600,0:17:09.600 to fully restore this extended state. So[br]it took two CVEs, but now luckily, they 0:17:09.600,0:17:15.760 all perform this nice full restore. So I[br]don't want to go to the full details of 0:17:15.760,0:17:21.280 our use cases now or of our case studies[br]that we did now. So let me just give you 0:17:21.280,0:17:29.440 the ideas of these case studies. So we[br]looked at these issues and wanted to look 0:17:29.440,0:17:36.800 into whether they just feel difficult or[br]whether they are bad. And we found that we 0:17:36.800,0:17:41.680 can use overflows as a side channel to[br]deduce secrets. So, for example, the 0:17:41.680,0:17:49.120 attacker could use this register to unmask[br]exceptions, that inside the 0:17:49.120,0:17:58.400 enclave are then triggered by some input[br]dependent multiplication. And we found out 0:17:58.400,0:18:03.040 that these side channels if you have some[br]input dependent multiplication can 0:18:03.040,0:18:11.920 actually be used in the enclave to perform[br]a binary search on this input space. And 0:18:11.920,0:18:16.880 we can actually retrieve this[br]multiplication secret with a deterministic 0:18:16.880,0:18:23.920 number of steps. So even though we just[br]have a single mask we flip, we can 0:18:23.920,0:18:31.760 actually retrieve a secret with[br]deterministic steps. And just for the, just 0:18:31.760,0:18:36.560 so that you know, there's more you can do.[br]We can also do machine learning in the 0:18:36.560,0:18:44.080 enclave. So Jo said it nicely, you can run[br]it inside the TEE, inside the cloud. And 0:18:44.080,0:18:47.760 that's great for machine learning, right?[br]So let's do a handwritten digit 0:18:47.760,0:18:55.200 recognition. And if you look at just the[br]model that we look at, we just have two 0:18:55.200,0:19:00.560 users where one user pushes some[br]machine learning model and the other user 0:19:00.560,0:19:05.520 pushes some input and everything is[br]protected with enclaves, right? 0:19:05.520,0:19:10.960 Everything is secure. But we actually[br]found out that we can poison these FPU 0:19:10.960,0:19:18.320 registers and degrade the performance of[br]this machine learning down from all digits 0:19:18.320,0:19:24.160 were predicted correctly to just eight[br]percent of digits were correctly. And 0:19:24.160,0:19:31.600 actually all digits were just predicting[br]the same number. And this basically made 0:19:31.600,0:19:37.520 this machine learning model useless,[br]right? There's more we did so we can also 0:19:37.520,0:19:42.320 attack blender with image differences,[br]slight image differences between blender 0:19:42.320,0:19:48.720 images. But this is just for you to see[br]that it's small, but it's a tricky thing 0:19:48.720,0:19:56.480 and indicate that that can go wrong very[br]fast on the ABI level once you play around 0:19:56.480,0:20:02.560 with it. So this is about the CPU state.[br]And now we will talk more about the 0:20:02.560,0:20:06.400 application programing interface that I[br]think more of you will be comfortable 0:20:06.400,0:20:09.440 with.[br]David: Yeah, we take, uh, thank you, 0:20:09.440,0:20:14.160 Fritz. We take a quite simple example. So[br]let's assume that we actually load a 0:20:14.160,0:20:18.560 standard Unix binary into such an enclave,[br]and there are frameworks that can do that, 0:20:18.560,0:20:24.960 such as graphene or so. And what I want to[br]illustrate with that example is that it's 0:20:24.960,0:20:29.680 actually very important to check where[br]pointers come from. Because the enclave 0:20:29.680,0:20:34.686 kind of partitions memory into untrusted[br]memory and enclave memory and they live in 0:20:34.686,0:20:40.800 a shared address space. So the problem[br]here is as follows. Let's assume we have 0:20:40.800,0:20:47.120 an echo binary that just prints an input.[br]And we give it as an argument a string and 0:20:47.120,0:20:52.720 that normally, when everything is fine,[br]points to some string, let's say hello 0:20:52.720,0:20:58.480 world, which is located in the untrusted[br]memory. So if everything runs as it 0:20:58.480,0:21:03.040 should, this enclave will run, will get[br]the pointer to untrusted memory and will 0:21:03.040,0:21:08.800 just print that string. But the problem is[br]now actually the enclave has access also 0:21:08.800,0:21:15.520 to its own trusted memory. So if you don't[br]check this pointer and the attacker passes 0:21:15.520,0:21:20.640 a pointed to the secret that might live in[br]enclave memory, what will happen? Well the 0:21:20.640,0:21:25.200 enclave will fetch it from there and will[br]just print it. So suddenly you have turned 0:21:25.200,0:21:32.080 this kind of like into a like a memory[br]disclosure vulnerability. And we can see 0:21:32.080,0:21:35.840 that in action here for the framework[br]named graphene that I mentioned. So we 0:21:35.840,0:21:40.640 have a very simple hello world binary and[br]we run it with a couple of command line 0:21:40.640,0:21:45.440 arguments. And now on the untrusted side,[br]we actually change a memory address to 0:21:45.440,0:21:50.080 point into enclave memory. And as you can[br]see, normally, it should print here test, 0:21:50.080,0:21:55.120 but actually it prints a super secret[br]enclave string that lived inside 0:21:55.120,0:22:00.960 the memory space of the enclave. So[br]these kind of vulnerabilities are quite 0:22:00.960,0:22:05.600 well known from user to kernel research[br]and from other instances. And they're 0:22:05.600,0:22:11.600 called confused deputy. So the deputy kind[br]of like has a gun now can read and if 0:22:11.600,0:22:17.280 memory and suddenly then does something[br]which is not not supposed to do because he 0:22:17.280,0:22:22.000 didn't really didn't really check where[br]the memory should belong or not. So I 0:22:22.000,0:22:27.600 think this vulnerability, uh, seems seems[br]to be quite trivial to solve. You simply 0:22:27.600,0:22:31.680 check all the time where, uh, where[br]pointers come from. But as you will tell, 0:22:31.680,0:22:37.920 you know, it's often not quite quite that[br]easy. Yes. David, that's quite insightful 0:22:37.920,0:22:41.840 that we should check all of the pointers.[br]So that's what we did. We checked all of 0:22:41.840,0:22:46.320 the pointer checks and we noticed that[br]Endo has a very interesting kind of all 0:22:46.320,0:22:49.760 the way to check these things. Of course,[br]the code is high quality. They checked all 0:22:49.760,0:22:53.360 of the pointers, but you have to do[br]something special for things. We're 0:22:53.360,0:22:57.840 talking here, the C programing language.[br]So things are no terminated, terminated. 0:22:57.840,0:23:02.880 They end with a new byte and you can use a[br]function as they are struggling to compute 0:23:02.880,0:23:05.920 the length of this thing. And let's see[br]how they check whether thing that's 0:23:05.920,0:23:10.880 completely outside of memory. So the first[br]step is you compute the length of the 0:23:10.880,0:23:15.600 interest, it's ten, and then you check[br]whether the string from start to end lives 0:23:15.600,0:23:19.280 completely outside of the anchor. That[br]sounds so legitimate. Then you eject the 0:23:19.280,0:23:23.760 steam. So so this works beautifully. Let's[br]see, however, how it behaves when we when 0:23:23.760,0:23:27.440 we partnered. And so we are not going to[br]parse this thing has a world outside of 0:23:27.440,0:23:34.160 the enclave that we pass on string secret,[br]one that lies within the. So the first 0:23:34.160,0:23:38.320 step will be that the conclave starts[br]computing the length of that string that 0:23:38.320,0:23:42.960 lies within the anklet. That sounds[br]already fishy, but then luckily everything 0:23:42.960,0:23:46.800 comes OK because then it will detect that[br]this actually should never have been done 0:23:46.800,0:23:50.880 and that this thing lies inside the[br]enclave. So it will reject the call so 0:23:50.880,0:23:56.080 that the call into the anklet. So that's[br]fine. But but some of you who know such 0:23:56.080,0:24:00.160 channels know that this is exciting[br]because the English did some competition 0:24:00.160,0:24:04.080 it was never supposed to do. And the[br]length of that competition depends on the 0:24:04.080,0:24:10.480 amount of of non-zero bites within the[br]anklet. So what we have here is a side 0:24:10.480,0:24:16.080 channel where the English will always[br]return false. But the time it takes to 0:24:16.080,0:24:21.600 return false depends on the amount of of[br]zero bytes inside that secret Arncliffe 0:24:21.600,0:24:26.640 memory block. So that's what we found. We[br]are excited and we said, OK, it's simple 0:24:26.640,0:24:31.920 timing channel. Let's go with that. So we[br]did that and you can see a graph here and 0:24:31.920,0:24:36.480 it turns out it's not as easy as it seems.[br]So I can tell you that the blue one is for 0:24:36.480,0:24:39.840 a string of length one, and that one is[br]for a string of like two. But there is no 0:24:39.840,0:24:43.760 way you can see that from that graph[br]because it said six processors are 0:24:43.760,0:24:47.920 lightning fast so that one single[br]incrementing section is completely 0:24:47.920,0:24:52.560 dissolves into the pipeline. You will not[br]see that by by measuring execution time. 0:24:52.560,0:24:59.120 So we need something different. And what[br]we have smart papers and in literature, 0:24:59.120,0:25:03.920 one of the very common attacks in ASICs is[br]also something that Intel describes here. 0:25:03.920,0:25:09.520 You can see which memory pages for memory[br]blocks are being accessed while the 0:25:09.520,0:25:14.080 English executes because you control the[br]operating system and the paging machinery. 0:25:14.880,0:25:19.680 So that's what we tried to do. We thought[br]this is a nice channel and we were there 0:25:19.680,0:25:24.480 scratching our heads, looking at that code[br]of very simple for loop that fits entirely 0:25:24.480,0:25:29.040 within one page and a very short string[br]that fits entirely within one page. So 0:25:29.040,0:25:33.920 just having access to for a memory, it's[br]not going to help us here because because 0:25:34.560,0:25:39.440 votes the code and the data fit on a[br]single page. So this is essentially what 0:25:39.440,0:25:44.320 we call the temporal resolution of the[br]sideshow. This is not accurate enough. So 0:25:44.320,0:25:51.040 we need a lot of take. And well, here we[br]have been working on quite an exciting 0:25:51.040,0:25:55.120 framework. It uses indirects and it's[br]called as a big step. So it's a completely 0:25:55.120,0:26:01.280 open source framework on Hadoop. And what[br]it allows you to do essentially is to 0:26:01.280,0:26:05.200 execute an enclave one step at a time,[br]hence the name. So it allows you to 0:26:05.200,0:26:09.040 interleave the execution of the enclave[br]with attacker code after every single 0:26:09.040,0:26:12.640 instruction. And the way we pull it off is[br]highly technical. We have this Linux 0:26:12.640,0:26:18.480 kernel drive around a little library[br]operating system in userspace, but that's 0:26:18.480,0:26:23.200 a bit out of scope. The matter is that we[br]can interrupt an enclave after every 0:26:23.200,0:26:27.538 single restriction and then let's see what[br]we can do with that. So. What we 0:26:27.538,0:26:33.720 essentially can do here is to execute and[br]follow up with all this extra increment 0:26:33.720,0:26:38.918 instructions one of the time, and after[br]every interrupt, we can simply check 0:26:38.918,0:26:45.066 whether the enclave accessed the string[br]residing of our target. That's another way 0:26:45.066,0:26:50.683 to think about it, is that we have that[br]execution of the enclave and we can break 0:26:50.683,0:26:56.998 that up into individual steps and then[br]just count the steps and hands and hands. 0:26:56.998,0:27:03.440 A deterministic timing. So in other words,[br]we have an oracle that tells you where all 0:27:03.440,0:27:08.824 zero bytes are in the anklet. I don't know[br]if that's useful, actually do so. It turns 0:27:08.824,0:27:12.737 out that this I mean, some people who[br]might be born into exploitation already 0:27:12.737,0:27:17.760 know that it's good to know whether zero[br]is somewhere in memory or not. And we do 0:27:17.760,0:27:23.537 now do one example where we break A-S and[br]Iowa, which is the hardware acceleration 0:27:23.537,0:27:29.000 of enterprises process for AI. So finally,[br]that actually operates only on registers. 0:27:29.000,0:27:34.130 And you just said you can kind of like do[br]that on onepoint us on memory, but says 0:27:34.130,0:27:38.832 another trick that comes into play here.[br]So whenever the enclave is interrupted, it 0:27:38.832,0:27:44.080 will store its current registers, date[br]somewhere to memory Quazi as a frame so we 0:27:44.080,0:27:50.425 can actually interrupt it and clarify make[br]it right. It's memory to to it's it's 0:27:50.425,0:27:56.840 register sorry to to say memory. And then[br]we can run the zero byte oracle on this 0:27:56.840,0:28:02.722 SSA a memory. And what we figure out is[br]where zero is or if there's any zero in 0:28:02.722,0:28:08.747 the state. So I don't want to go into the[br]gory details of a yes. But what we 0:28:08.747,0:28:15.835 basically do is we find whenever there's a[br]zero in the last in the state before the 0:28:15.835,0:28:21.850 last round of ads and then that zero will[br]go down to the box will be X or to a key 0:28:21.850,0:28:27.520 byte, and then that will give us a cipher[br]text. But we actually know the ciphertext 0:28:27.520,0:28:33.601 byte so we can go backwards. So we can[br]kind of compute, uh, we can compute from 0:28:33.601,0:28:39.763 zero up to here and from here to this X1.[br]And that way we can compute directly one 0:28:39.763,0:28:45.840 key byte. So we repeat that whole thing 16[br]times until we have found a zero in every 0:28:45.840,0:28:51.460 bite of this state before the last round.[br]And that way we get the whole final round 0:28:51.460,0:28:56.294 key. And for those that know as if you[br]have one round key, you have the whole key 0:28:56.294,0:29:00.654 in it. So you get like the original key,[br]you can go backwards. So sounds 0:29:00.654,0:29:05.988 complicated, but it's actually a very fast[br]attack when you see it running. So here is 0:29:05.988,0:29:11.473 a except doing this attack and as you can[br]see, was in a couple of seconds and maybe 0:29:11.473,0:29:16.342 five hundred twenty invocations of of[br]Asir, we get the full KeIso. That's 0:29:16.342,0:29:21.401 actually quite impressive, especially[br]because the whole uh. Yeah, one of the 0:29:21.401,0:29:26.268 points in essence is that you don't put[br]anything in memory, but this is 0:29:26.268,0:29:33.062 interaction with SGX, which is kind of[br]like allows you to put stuff into into 0:29:33.062,0:29:41.372 memory. So I want to wrap up here. Um, we[br]have found various other attacks. Yeah. 0:29:41.372,0:29:47.838 So, um, both in research code and in[br]production code, such as the Intel SDK and 0:29:47.838,0:29:52.708 the Microsoft SDK. And they basically go[br]across the whole range of foreign 0:29:52.708,0:29:57.700 abilities that we have often seen already[br]from use it to kind of research. But there 0:29:57.700,0:30:02.680 are also some, uh, some interesting new[br]new kind of like vulnerabilities due to 0:30:02.680,0:30:08.240 some of the aspects we explained. There[br]was also a problem with all call centers 0:30:08.240,0:30:13.770 when the enclave calls into untrust, the[br]codes that is used when you want to, for 0:30:13.770,0:30:18.740 instance, emulate system calls and so on.[br]And if you return some kind of like a 0:30:18.740,0:30:24.839 wrong result here, you could again go out[br]of out of bounds. And they were actually 0:30:24.839,0:30:30.697 quite, quite widespread. And then finally,[br]we also found some issues with padding, 0:30:30.697,0:30:36.115 with leakage in the padding. I don't want[br]to go into details. I think we have, uh, 0:30:36.115,0:30:40.880 learned a lesson here that that we also[br]know from from the real world. And that is 0:30:40.880,0:30:47.105 it's important to wash your hands. So it's[br]also important to sanitize and state to 0:30:47.105,0:30:54.213 check pointers and so on. No. So that is[br]kind of one one of the take away message 0:30:54.213,0:30:58.585 is really that to build and connect[br]securely, yes, you need to fix all the 0:30:58.585,0:31:03.445 hardware issues, but you also need to[br]write safe code. And for enclave's, that 0:31:03.445,0:31:09.674 means you have to do a proper API and APIs[br]sanitization. And that's quite a difficult 0:31:09.674,0:31:15.718 task actually, as as we've seen, I think[br]in that presentation, there's quite a 0:31:15.718,0:31:21.066 large attack surface due to the attack[br]model, especially of intellectual X, where 0:31:21.066,0:31:25.781 you can interrupt after every instruction[br]and so on. And I think for from a research 0:31:25.781,0:31:31.888 perspective, there's really a need for a[br]more. Approach, then just continue if you 0:31:31.888,0:31:38.010 want, maybe we can learn something from[br]from the user to analogy which which I 0:31:38.010,0:31:43.734 invoked, I think a couple of times so we[br]can learn kind of like how what an enclave 0:31:43.734,0:31:48.650 should do, uh, from from what we know[br]about what a colonel should do. But they 0:31:48.650,0:31:54.239 are quite important differences also that[br]need to be taken account. So I think, as 0:31:54.239,0:31:59.670 you said, all all our code is is open[br]source. So you can find that on the below 0:31:59.670,0:32:07.016 GitHub links and you can, of course, ask[br]also questions after you have watched this 0:32:07.016,0:32:15.077 talk. So thank you very much. Hello, so[br]back again. Here are the questions. Hello 0:32:15.077,0:32:21.680 to see your life. Um, we have no questions[br]yet, so you can put up questions in the 0:32:21.680,0:32:28.200 see below if you have questions. And on[br]the other hand. Oh, let me make close this 0:32:28.200,0:32:36.751 up so I'll ask you some questions. How did[br]you come about this topic and how did you 0:32:36.751,0:32:43.484 meet? Uh, well, that's actually[br]interesting. I think this such as has been 0:32:43.484,0:32:50.158 building up over the years. Um, and it's[br]so, so, so I think some some of the 0:32:50.158,0:32:56.691 vulnerabilities from our initial paper, I[br]actually started in my master's thesis to 0:32:56.691,0:33:01.763 sort of see and collect and we didn't[br]really see the big picture until I think I 0:33:01.763,0:33:06.774 met David and his colleagues from[br]Birmingham at an event in London, the nice 0:33:06.774,0:33:11.326 conference. And then we we started to[br]collaborate on this and we went to look at 0:33:11.326,0:33:14.955 this a bit more systematic. So I started[br]with this whole list of vulnerabilities 0:33:14.955,0:33:19.880 and then with with David, we kind of made[br]it into a more systematic analysis. And 0:33:19.880,0:33:26.362 and that was sort of a Pandora's box. I[br]dare to say from the moment on this, this 0:33:26.362,0:33:32.003 kind of same errors being repeated. And[br]then also Fitzhugh, who recently joined 0:33:32.003,0:33:36.237 our team in London, started working[br]together with us on one or more of these 0:33:36.237,0:33:40.520 low level Sebu estate. And that's the[br]Pandora's box in itself. I would say, 0:33:40.520,0:33:46.506 especially one of the lessons, as we said,[br]that particular six is extremely complex. 0:33:46.506,0:33:51.233 And it turns out that almost all of that[br]complexity, I would say, can be abused, 0:33:51.233,0:33:55.904 potentially biodiversity. So it's more[br]like a fractal in a fraction of a fractal 0:33:55.904,0:34:01.831 where you're opening a box and you're[br]getting more and more of questions out of 0:34:01.831,0:34:08.731 that. In a way, I think. Yes, I think it's[br]fair to say this this research is not the 0:34:08.731,0:34:13.573 final answer to to this, but it's an[br]attempt to to give a systematic way of 0:34:13.573,0:34:19.068 looking at probably never ending up[br]actually funding is. So there is a 0:34:19.068,0:34:26.034 question from the Internet. So are there[br]any other circumstances where he has 0:34:26.034,0:34:33.188 Mianus and he is writing its registers[br]into memory, or is this executed exclusive 0:34:33.188,0:34:44.160 to SGX? So I repeat, I do not understand[br]the question either, so, so well, I think 0:34:44.160,0:34:49.280 the question is that this is a tactical[br]defeat. Prison depends on, of course, 0:34:50.000,0:34:54.720 having a memory disclosure about the[br]content and people that are accusing us 0:34:54.720,0:34:58.960 except to kind of forcibly right the[br]memory content of the content into memory. 0:35:00.000,0:35:05.040 So that is definitely a specific um.[br]However, I would say one of the the 0:35:05.040,0:35:08.960 lessons from the past five years of[br]research is that often these things 0:35:08.960,0:35:13.200 generalize beyond the six and at least the[br]general concept of, let's say, the 0:35:13.200,0:35:18.880 insights that sebu, that justice end up in[br]memory one way or another sooner or later. 0:35:18.880,0:35:23.040 I think that also applies to creating[br]systems that if you somehow can force an 0:35:23.040,0:35:26.080 operating system to complex, which pertain[br]to applications, that you also have to 0:35:27.200,0:35:32.160 register temporarily in memory. So if you[br]would have something similar like what we 0:35:32.160,0:35:37.200 have in an operating system, Colonel, you[br]would potentially mount a similar attack. 0:35:37.760,0:35:43.680 But maybe David wants to say something[br]about operating systems there as well. No, 0:35:43.680,0:35:48.240 no, not really. I think, like one one[br]thing that helps with SGX is that you have 0:35:48.240,0:35:53.200 very precise control, as you explained,[br]which was the interrupts and stuff because 0:35:53.200,0:35:58.080 you were your route outside the outside[br]the enclave. So you can signal step 0:35:58.080,0:36:03.280 essentially the whole enclave where it's[br]like, um, interrupting the operating 0:36:03.280,0:36:08.320 system. Exactly repeatedly at exactly the[br]point you want or some other process also 0:36:09.120,0:36:13.760 tends to be probably probably harder just[br]by design. But of course, on a context 0:36:13.760,0:36:19.360 which keep us to save somewhere, it's[br]register set and then then it will end up 0:36:19.360,0:36:25.840 in memoria in some situations probably not[br]not as controlled as it is for for as 0:36:25.840,0:36:34.480 Asgeirsson. So there is the question, what[br]about other CPU architectures other than 0:36:34.480,0:36:41.840 Intel, did you test those? So maybe I can[br]I can go into this so. Well, interesting. 0:36:41.840,0:36:48.160 See, that's the largest one with the[br]largest software base and the most runtime 0:36:48.160,0:36:53.440 that is also that we could look at. Right.[br]But there, of course, some other stuff we 0:36:53.440,0:37:01.040 have or as this eternity that we developed[br]some years ago, it's called Sancho's. And 0:37:01.040,0:37:05.440 of course, for this, there are similar[br]issues. Right. So you always need the 0:37:05.440,0:37:14.880 software layer to interact, to enter the[br]enclave into the enclave. And I think you 0:37:14.880,0:37:20.880 had David in the earlier work, also found[br]issues in our TI. So it's not just Intel 0:37:20.880,0:37:27.120 and really related product projects that[br]mess up there, of course. But what we 0:37:27.120,0:37:34.000 definitely found is it's easier to to[br]think of all cases for simpler designs 0:37:34.000,0:37:38.080 like risk five or simpler risk designs[br]then for this complex actually six 0:37:39.360,0:37:43.840 architecture. Right. So right now there[br]are not that many sites into less Jicks. 0:37:43.840,0:37:48.880 So so they have the advantage and[br]disadvantage of being the first widely 0:37:48.880,0:37:56.000 deployed, let's say. And um, but I think[br]as soon as others start to, to grow out 0:37:56.000,0:38:00.960 and simpler designs start to be more[br]common, I think we will see this, that 0:38:00.960,0:38:05.649 it's easier to fix alleged cases for[br]simpler designs. OK, so what is a 0:38:05.649,0:38:18.966 reasonable alternative to tea, or is there[br]any way you want to take that or think, 0:38:18.966,0:38:27.215 should I say what? Uh, well, we can[br]probably both give our perspectives. So I 0:38:27.215,0:38:31.842 think. Well, the question to start[br]statute, of course, is do we need an 0:38:31.842,0:38:34.992 alternative or do we need to find more[br]systematic ways to to to sanitize 0:38:34.992,0:38:39.212 Australians? That's, I think, one part of[br]the answer here, that we don't have to 0:38:39.212,0:38:43.240 necessarily throw away these because we[br]have problems with them. We can also look 0:38:43.240,0:38:46.990 at how to solve those problems. But apart[br]from that, there is some exciting 0:38:46.990,0:38:52.124 research. OK, maybe David also wants to[br]say a bit more about, for instance, on 0:38:52.124,0:38:57.305 capabilities, but that's not in a way not[br]so different than these necessarily. But 0:38:57.305,0:39:00.864 but when you have high tech support for[br]capabilities like like the Cherry 0:39:00.864,0:39:04.646 Borjesson computer, which essentially[br]associates metadata to a point of 0:39:04.646,0:39:09.692 metadata, like commission checks, then you[br]could at least for some cause of the 0:39:09.692,0:39:14.837 issues we talked about point to point of[br]poisoning attacks, you could natively 0:39:14.837,0:39:20.651 catch those without support. But but it's[br]a very high level idea. Maybe David wants 0:39:20.651,0:39:26.080 to say something. Yeah. So so I think,[br]like alternative to tea is whenever you 0:39:26.080,0:39:31.640 want to partition your system into into[br]parts, which is, I think, a good idea. And 0:39:31.640,0:39:37.523 everybody is now doing that also in there,[br]how we build online services and stuff so 0:39:37.523,0:39:44.276 that these are one systems that we have[br]become quite used to from from mobile 0:39:44.276,0:39:48.976 phones or from maybe even even from[br]something like a banking card or so out, 0:39:48.976,0:39:52.729 which is sort of like a protected[br]environment for a very simple job. But the 0:39:52.729,0:39:57.501 problem then starts when you throw a lot[br]of functionality into the tea. As we saw, 0:39:57.501,0:40:03.318 the trusted code base becomes more and[br]more complex and you get traditional box. 0:40:03.318,0:40:08.059 So I'm saying like, yeah, it's really a[br]question if you need an alternative or a 0:40:08.059,0:40:11.794 better way of approaching it. How are you[br]partition software? And as you mentioned, 0:40:11.794,0:40:16.406 there are some other things you can do[br]architecturally so you can change the way 0:40:16.406,0:40:21.386 we or extends the way we build build[br]architectures for with capabilities and 0:40:21.386,0:40:25.955 then start to isolate components. For[br]instance, in one software project, say it, 0:40:25.955,0:40:30.299 say in your Web server, you isolate the[br]stack or something like this. And also, 0:40:30.299,0:40:37.526 thanks for the people noticing the secret[br]password here. You so obviously only for 0:40:37.526,0:40:45.854 decoration purposes to give the people[br]something to watch. So but it's not 0:40:45.854,0:40:54.612 fundamentally broken, isn't? Yeah, not 60.[br]I mean, these are so many of them, I 0:40:54.612,0:41:02.261 think, like you cannot say, fundamentally[br]broken for but for a question I had was 0:41:02.261,0:41:08.342 specifically for SGX at that point,[br]because signal uses its mobile coin, 0:41:08.342,0:41:15.680 cryptocurrency uses it and so on and so[br]forth. Is that fundamentally broken or 0:41:15.680,0:41:24.428 would you rather say so? So I guess it[br]depends what you call fundamentally right. 0:41:24.428,0:41:29.915 So there has been in the past, we have[br]worked also on what I would say for 0:41:29.915,0:41:35.107 breaches of attitudes, but they have been[br]fixed and it's actually quite a beautiful 0:41:35.107,0:41:40.909 instance of a well researched and have[br]short term industry impact. So you find a 0:41:40.909,0:41:45.924 vulnerability, then the vendor has to[br]devise a fix that they are often not 0:41:45.924,0:41:50.014 available and there are often workarounds[br]to the problem. And then the later, 0:41:50.014,0:41:54.432 because you're are talking, of course,[br]about how to talk to. So then you need new 0:41:54.432,0:41:58.668 processes to really get a fundamental fix[br]for the problem and then you have 0:41:58.668,0:42:04.655 temporary workarounds. So I would say, for[br]instance, a company like Signeul using it, 0:42:04.655,0:42:10.059 if they so it does not give you security[br]by default. But you need to think about 0:42:10.059,0:42:14.108 the software. That's what you focused on[br]in this stock. We also need to think about 0:42:14.108,0:42:20.394 all of the hardware, micro patches and on[br]the processors to take care of all the 0:42:20.394,0:42:26.470 known vulnerabilities. And then, of[br]course, the question always remains, are 0:42:26.470,0:42:30.824 the abilities that we don't know of yet[br]with any secure system? I guess. But but 0:42:30.824,0:42:36.676 maybe also David wants to say something[br]about some of his latest work there. 0:42:36.676,0:42:42.504 That's a bit interesting. Yeah. So I think[br]what what your source or my answer to this 0:42:42.504,0:42:48.083 question would be, it depends on your[br]threat model, really. So some some people 0:42:48.083,0:42:54.045 use SGX as a way to kind of like remove[br]the trust in the cloud provider. So you 0:42:54.045,0:42:59.511 say like RSS and Signaler. So I move all[br]this functionality that that is hosted 0:42:59.511,0:43:04.655 maybe on some cloud provider into an[br]enclave and then then I don't have to 0:43:04.655,0:43:10.673 trust the cloud provider anymore because[br]there's also some form of protection 0:43:10.673,0:43:15.760 against physical access. But recently we[br]actually we published another attack, 0:43:15.760,0:43:22.130 which shows that if you have hardware[br]access to an SGX processor, you can inject 0:43:22.130,0:43:28.138 false into into the processor by playing[br]with the on the voting interface with was 0:43:28.138,0:43:33.155 hardware. And so you really saw that to[br]the main board to to a couple of a couple 0:43:33.155,0:43:38.442 of wires on the bus to the voltage[br]regulator. And then you can do voltage 0:43:38.442,0:43:43.824 glitching, as some people might know, from[br]from other embedded contexts. And that way 0:43:43.824,0:43:48.680 then you can flip bits essentially in the[br]enclave and of course, do all kinds of, 0:43:48.680,0:43:54.589 um, it kind of like inject all kinds of[br]evil effects that then can be used further 0:43:54.589,0:43:59.612 to get keys out or maybe hijack control[br]flow or something. So it depends on your 0:43:59.612,0:44:04.802 threat model. I wouldn't say so. That ASX[br]is completely pointless. It's, I think, 0:44:04.802,0:44:10.200 better than not having it at all. But it[br]definitely cannot you cannot have, like, 0:44:10.200,0:44:15.314 complete protection against somebody who[br]has physical access to your server. So I 0:44:15.314,0:44:20.880 have to close this talk. It's a bummer.[br]And I would ask all the questions that I 0:44:20.880,0:44:26.100 flew in. But one very, very fast answer,[br]please. What is that with a password in 0:44:26.100,0:44:30.627 your background? I explained it. It's[br]it's, of course, like just a joke. So I'll 0:44:30.627,0:44:35.609 say it again, because some people seem to[br]have taken it seriously. So it was such an 0:44:35.609,0:44:40.438 empty whiteboard. So I put a password[br]there. Unfortunately, it's not fully 0:44:40.438,0:44:46.234 visible in the in the screen. OK, so I[br]think you should open book out of David 0:44:46.234,0:45:00.100 Oswald. Thank you for having that nice[br]talk. And now we make the transition to 0:45:00.100,0:45:03.840 the new show. 0:45:03.840,0:45:34.000 Subtitles created by c3subtitles.de[br]in the year 2021. Join, and help us!