Ramming Enclave Gates: A Systematic Vulnerability Assessment of TEE Shielding Runtimes
Bulck, Jo Van
Alder, Fritz
Oswald, David
This talk presents an extensive security analysis of trusted-execution environment shielding runtimes, covering over two years of continuing research and leading to 7 CVE designations in industry-grade Intel SGX enclave SDKs. For the first time, we develop a systematic way of reasoning about enclave shielding responsibilities categorized across 11 distinct classes across the ABI and API tiers. Our analysis revealed over 40 new interface sanitization vulnerabilities, and we developed innovative techniques to aid practically exploitation through among others CPU register poisoning, timer-based single-stepping, rogue CPU exception handlers, and side-channel-based cryptanalysis. We finally analyze tendencies across the landscape and find that developers continue to make the same mistakes, calling for improved vulnerability detection and mitigation techniques. This talk overviews the security and state of practice of today's Trusted Execution Environment (TEE) shielding runtimes from both industry and research. Our systematic analysis uncovered over 40 re-occurring enclave interface sanitization vulnerabilities in 8 major open-source shielding frameworks for Intel SGX, RISC-V, and Sancus TEEs. The resulting vulnerability landscape enables attackers to poison victim programs through both low-level CPU state, including previously overlooked attack vectors through the x86 status flags and floating-point co-processor, as well as through higher-level programming constructs such as untrusted pointer arguments passed into the shared address space. We develop new and improved technique to practically exploit these vulnerabilities in several attack scenarios that leak full cryptographic keys from the enclave or enable arbitrary remote code reuse. Following extended responsible disclosure embargoes, our findings were assigned 7 designated CVE records and led to numerous security patches in the vulnerable open-source projects, including the Intel SGX-SDK, Microsoft's Open Enclave, Google's Asylo, and the Rust compiler. Our findings highlight that emerging TEE technologies, such as Intel SGX, are _not_ a silver-bullet solution and continue to be misunderstood in both industry and academia. While promising, we explain that TEEs require extra scrutiny from the enclave developer and we set out to identify common pitfalls and constructive recommendations for best practices for enclave interface sanitization. Throughout the talk, we overview shielding responsibilities and argue that proper enclave hygiene will be instrumental to the success of the emerging Intel SGX ecosystem. Additionally, we point to several subtle properties of the Intel x86 complex instruction set considerably increase the attack surface for enclave attackers and require the end developer to be aware of their respective shielding runtime or apply additional sanitizations at the application level itself.
 So, for the next talk, I have Jo van Bulk and Fritz Alder from the University of Löwen in Belgium and David Oswald, a professor for cybersecurity in Birmingham. They are here to talk about the trusted execution environment you probably know from Intel and so on. And you should probably not trust it all the way because it's software and it has its flaws. And so they're talking about ramming enclave gates, which is always good, a systematic vulnerability assessment of TE shielding runtimes. Please go on with the talk. Hi everyone, welcome to our talk. So I'm Jo from the E-Mate Disonet Research Group at Kea Löwen. And today joining me are Fritz also from Löwen and David from the University of Birmingham. And we have this very exciting topic to talk about ramming enclave gates. But before we dive into that, I think most of you will not know what are enclaves, let alone what are these TEs. So let me first start with some analogy. So enclaves are essentially sort of a secure fortress in the processor in the CPU. And so it's an encrypted memory region that is exclusively accessible from the inside. And what we know from the last history of fortress attacks and defenses, of course, is that when you cannot take a fortress because the walls are high and strong, you typically aim for the gates, right? That's the weakest point in any fortress defense. And that's exactly the idea of this research. So it turns out to apply to enclaves as well. And we have been ramming the enclave gate. We have been attacking the input-output interface of the enclave. So a very simple idea, but very drastic consequences, I dare to say. So this is sort of the summary of our research with over 40 interface sanitization vulnerabilities that we found in over eight widely used open source enclave projects. So we will go a bit into detail over that in the rest of the slides. Also, a nice thing to say here is that this resulted in two academic papers to date, over seven CVEs, and altogether quite some responsible disclosure lengthy and viral periods. OK, so I guess we should talk about why we need such enclave fortresses anyway. So if you look at traditional kind of like operating system or computer architecture, you have a very large trusted computing base. So for instance, on the laptops that you most likely use to watch this talk, you trust the kernel, you trust maybe a hypervisor if you have, and the whole hardware under the system, so CPU, memory, maybe hard drive, trusted platform module, and the likes. So actually the problem is here with such a large TCB, trusted computing base, you can also have vulnerabilities basically everywhere, and also malware hiding in all these parts. So the idea of this enclave execution is, as we find for instance in Intel SGX, which is built into most recent Intel processors, is that you take most of the software stack between an actual application, here the enclave app, and the actual CPU out of the TCB. So now you only trust really the CPU, and of course you trust your own code, but you don't have to trust the OS anymore, and SGX for instance promises to protect against an attacker who has achieved a route in the operating system, and even depending on who you ask against, for instance a malicious cloud provider, so imagine you run your application on the cloud, and then you can still run your code in a trusted way, with hardware level isolation, and you have attestation and so on, and you no longer really have to trust even the administrator. So the problem is of course that attack surface remains, so previous attacks and some of them I think will also be presented at this remote congress this year, have targeted vulnerabilities in the micro architecture of the CPU. So you are attacking basically the hardware level, so you have foreshadow, you have micro architecture data sampling, specter and LVI and the likes, but what less attention has been paid to, and what we'll talk about more in this presentation, is the software level inside the enclave, which I hinted at, that there's some software that you trust, but now we look in more detail into what actually is in such an enclave from the software side. So can an attacker exploit any classical software vulnerabilities in the enclave? Yes, David, that's quite an interesting approach, right? Let's aim for the software, so we have to understand what is the software landscape out there for these SGX enclaves and DEs in general. So that's what we did, we started with an analysis and you see some screenshots here, this is actually a growing open source ecosystem, many of these run times, library opening system SDKs. And before we dive into the details, I want to stand still with what is the common factor that all of them share, right? What is kind of the idea of these enclave development environments? So here, what any DE to set execution environment gives you is this notion of a secure enclave oasis in a hostile environment, right? And you can do secure computations in that green box while the outside world is burning. As with any defense mechanism, as I said earlier, the devil is in the details and typically at the gate, right? So how do you mediate between that undisturbed world where the desert is on fire and the secure oasis in the enclave? And the intuition here is that you need some sort of intermediary software layer, which what we call a shielding runtime. So it kind of makes a secure bridge to go from the interstitled to the enclave and back. And that's what we are interested in, right? To see what kind of security checks you need to do there. So it's quite a beautiful picture. You have on the right the fertile enclave, and on the left the hostile desert. And we make this secure bridge in between. And what we are interested in is what if it goes wrong? What if your bridge itself is flawed? So to answer that question, we look at that yellow box and we ask what kind of sanitizations, what kind of security checks do you need to apply when you go from the outside to the inside and back from the inside to the outside? And one of the key contributions that we have built up in the past two years of this research, I think, is that the yellow box can be subdivided into two smaller subsequent layers. And the first one is this ABI application binary interface, very low level CPU state. And the second one is what we call API application programming interface. So that's the kind of state that's already visible at the programming language. Then the remainder of this presentation, we will kind of guide you through some relevant vulnerabilities at both these layers to give you an understanding of what this means. So first Fritz will guide you to the exciting low level landscape of the ABI. Yeah, exactly. And you just said it's the CPU state, and it's the application binary interface. But let's take a look at what this means, actually. So it means basically that the attacker controls the CPU register contents. And we do have to proceed. And that on every enclave entry or on every enclave exit, we need to perform some tasks so that the enclave and the trust runtime have some well initialized CPU state. And the compiler can work with the calling conventions that it expects. So these are basically the key part. We need to initialize the CPU registers when entering the enclave and scrubbing them when we exit the enclave. So we can't just assume anything that the attacker gives us as a given. We have to initialize it to something proper. And we looked at multiple TTE runtimes and then multiple TEs. And we found a lot of vulnerabilities in this ABI layer. And one key insight of this analysis is basically that a lot of these vulnerabilities happen on complex instruction set processors. So on CISC processors. And basically on the InternetGX TTE. We also looked at some RISC processors. And of course, it's not representative. But it's immediately visible that a complex x86 ABI seems to have a way higher, larger tech surface than the simpler RISC designs. So let's take a look at one example of this more complex design. So for example, there's the x86 string instructions that are controlled by the direction flag. So there's a special x86 rep instruction that basically allows you to perform stream memory operations. So if you do like a memset on a buffer, this will be compiled into the rep string operation instruction. And the idea here is basically that the buffer is read from left to right and well, written over by memset. But this direction flag also allows you to go through it from right to left, so backwards. Let's not think about why this was a good idea or why this is needed. But definitely it is possible to just set the direction flag to one and run this buffer backwards. And what we found out is that the system VABI actually says that this must be clear or set to forward on function entry and return. And that compilers expect this to happen. So let's take a look at this when we do this in our enclave. So in our enclave, when we in our trusted application perform this memset on our buffer, on normal entry with the normal direction flag, this just means that we walk this buffer from front to back. So you can see here, it just runs correctly from front to back. But now if the attacker enters the enclave with the direct direction flag set to one, so it sets to run backwards, this now means that from the start of our buffer, so from where the pointer points right now, you can now see it actually runs backwards. So that's the problem. And that's definitely something that we don't want in our trust applications. Because, well, as you can think, it allows you to override keys that are in the memory locations that you can go backwards. It allows you to read out things. That's definitely not something that is useful. And when we reported this, this actually got a nice CD assigned with the base core high, as you can see here in the next slide. And, well, you may think, OK, well, that's one instance. And you just have to think of all the flex to sanitize and all the flex to check. But wait, of course, there's always more. So as we found out, there's actually the floating point units, which comes with a whole lot of other registers and a whole lot of other things to exploit. And I will spare you all the details. But just for this presentation, just know that there is an older x87FPU and new SSE that does vector float. This is vector floating point operations. So there's the FPU control word and the MXCSR register for these newer instructions. And this x87FPU is older, but it's still used, for example, for extended precision, like long double variables. So old and new doesn't really apply here because both are still relevant. And that's kind of the thing with x86 and x87 here, that old archaic things that you could say are outdated are still relevant or are still used nowadays. And again, if you look at the system VABI now, we saw that these control bits are coalescated. So they are preserved across function codes. And the idea here is, which to some degree holds merit, is that these are some global states that you can set. And they are transferred within one application. So one application can set some global state and keeps the state across all its usage. But the problem here, as you can see here, then is our application or Enclave is basically one application. And we don't want our attacker to have control over the global state within our trusted application. So what happens if PUS settings are preserved across codes? Well, for a normal user, let's say we just do some calculation inside the Enclave, like 2.1 times 3.4, which just nicely calculates to a 7.14 long double. That's nice. But what happens if the attacker now enters the Enclave with some corrupt precision and rounding modes for the FPU? Well, then we actually get another result. So we get distorted results with the lower precision and different rounding modes. So it's actually rounding down here, whenever it exceeds the precision. And this is something we don't want. So this is something where the developer expects certain precision or a long double precision, but the attacker could actually just reduce it to a very short precision. And we reported this, and we actually found this issue also in Microsoft Open Enclave. That's why it's marked as not exploitable here. But what we found interesting is that the Intel SGX SDK, which was vulnerable, patched this with an X restore instruction, which completely restores the extended state to a known value. While Open Enclave only restores the specific register that was affected, the load MXC SR instruction. And so let's just skip over the next few slides here, because I just want to give you the idea that this was not enough. So we found out that even if you restore this specific register, there's still another data register that you can just mark as in use before entering the Enclave, and with which the attacker can make that any floating point calculation results in another number. And this is silent, so this is not programming language specific, this is not developer specific. This is a silent ABI issue that the calculations are just not a number. So we also reported this. And now, thankfully, all Enclave runtime uses full X restore instruction to fully restore this extended state. So it took two CDs, but now luckily, they all perform this nice full restore. So I don't want to go into the full details of our use cases now or of our case studies that we did now. So let me just give you the ideas of these case studies. So we looked at these issues and wanted to look into whether they just feel difficult or whether they are a bet. And we found that we can use overflows as a side channel to deduce secrets. So for example, the attacker could use this register to unmask exceptions that inside the Enclave are then triggered by some input dependent multiplication. And we found out that these side channels, if you have some input dependent multiplication, can actually be used in the Enclave to perform a binary search on this input space. And we can actually retrieve this multiplication secret with a deterministic number of steps. So even though we adjust it like a single mask, we flip, we can actually retrieve the secret with deterministic steps. And just so that you know there's more you can do, we can also do machine learning in the Enclave. So if you all said it nicely, you can run it inside the TE, inside the cloud. And that's great for machine learning, right? So let's do hand written digit recognition. And if you look at just the model that we look at, we just have two users where one user pushes some machine learning model and the other user pushes some input. And everything is protected with Enclave, right? So everything is secure. But we actually found out that we can poison these FPU registers and degrade the performance of this machine learning down from all digits were predicted correctly to just 8% of digits were correctly. And actually, all digits were just predicted the same number. And this basically made this machine learning model useless. There's more we did. So we can also attack Blender with image differences, slight differences between Blender images. But that's just for you to see that it's small. But it's a tricky thing and intricate that can go wrong very fast on the ABI level once you play around with it. So this is about the CPU state. And now we will talk more about the application programming interface that I think more of you will be comfortable with. Yeah, we take, thank you Fritz. We take quite a simple example. So let's assume that we actually load the standard Unix binary into such an Enclave. And there are frameworks that can do that, such as a Graphina. So and what I want to illustrate with that example is that it's actually very important to check where a point has come from. Because the Enclave kind of partitions the memory into untrusted memory and Enclave memory. And they live in a shared address space. So the problem here is as follows. Let's assume we have an echo binary that just prints an input. And we give it as an argument string. And that normally, when everything is fine now, points to some string, let's say, hello world, which is located in the untrusted memory. So if everything runs as it should, this Enclave will run, will get the pointer to untrusted memory, and will just print that string. But the problem is now actually the Enclave has access also to its own trusted memory. So if you don't check this pointer and the attacker passes a pointer to the secret that might live in Enclave memory, what will happen? Well, the Enclave will fetch it from there and will just print it. So suddenly you have turned this kind of like into a memory disclosure vulnerability. And we can see that in action here for the framework named Graphine that I mentioned. So we have a very simple hello world binary. And we run it with a couple of command line arguments. And now in on the untrusted side, we actually change a memory address to point into Enclave memory. And as you can see, normally it should print here test. But actually it prints a super secret Enclave string that lift inside the memory space of the Enclave. So these kind of vulnerabilities are quite well known from user to kernel research and from other instances. And they're called confused deputies. So the deputies kind of like has a gun, can read the Enclave memory and suddenly then does something which is not supposed to do because it didn't really check where the memory should belong or not. So I think this vulnerability seems to be quite trivial to solve. You simply check all the time where pointers come from. But as you will tell, it's often not quite that easy. Yes, David, that's quite insightful. We should check all of the pointers. So that's what we did. We checked all of the pointer checks. And we noticed that Intel has a very interesting kind of algorithm to check these things. Of course, the Intel code is high quality. They checked all of the pointers. But you have to do something special for strings. And we're talking here the C programming language. So strings are null terminated. They end with a null byte. And you can use the function sdln string length to compute the length of the string. And let's see how they check whether your string lights completely outside of Enclave memory. So the first step is you compute the length of the interested string. And then you check whether the string from start to end lights completely outside of the Enclave. That sounds legit, right? And you reject the string. So this works beautifully. Let's see however how it behaves when we pass on a legal string. So we are not going to pass the string hello world outside of the Enclave. But we pass some string secret one that lies within the Enclave. So the first step will be that the Enclave starts computing the length of that string that lies within the Enclave. And that sounds already fishy. But then luckily everything comes OK, because then it will detect that this actually should never have been done and that the string lies inside the Enclave. So it will reject the e-cals, or the call into the Enclave. So that's fine. But some of you who know side channels know that this is exciting, right? Because the Enclave did some computation it was never supposed to do. And the length of that computation depends on the amount of non-zero bytes within the Enclave. So what we have here is a side channel where the Enclave will always return false. But the time it takes to return false depends on the amount of zero bytes inside that secret Enclave memory blob. So that's what we found. We were excited. And we said, OK, that's a simple timing channel. Let's go to that. So we did that. And you can see a graph here. And it turns out it's not as easy as it seems, right? So I can tell you that the blue one is for a string of length one and the red one is for a string of length two. But there is no way you can see that from that graph. Because x86 processors are lightning fast so that one single increment instruction is completely dissolves into the pipeline. You will not see that by measuring execution time. So we need something different. And while we are smart, so we read papers. And in literature, one of the very common attacks in SJX is also something that Intel describes here. You can see which memory pages 4K memory blocks are being accessed while the Enclave executes because you control the operating system and the paging machinery in there. So that's what we tried to do. And we thought this is a nice side channel. And we were there sketching our head looking at that code, a very simple for loop that fits entirely within one page and a very short string that fits entirely within one page. So just having access to 4K memory regions is not going to help us here, right? Because vote the code and the data fit on a single page. So this is essentially what we call the temporal resolution of the side channel. This is not accurate enough. So we need another trick. And well, here we have been working on quite an exciting framework. It uses interrupts. And it's called SGX Step. So it's a completely open source framework on Hitup. And what it allows you to do essentially is to execute an Enclave one step at a time. Hence the name. So it allows you to interleave the execution of the Enclave with attacker code after every single instruction. And the way we pulled it off is highly technical. We have this Linux kernel driver and a little library operating system running in user space. But that's a bit out of scope. The matter is that we can interrupt an Enclave after every single instruction. And then let's see what we can do with that. So what we essentially can do here is to execute that for loop with all these x86 increment instructions one at a time. And after every interrupt, we can simply check whether the Enclave accessed the string residing at our target as memory location. Another way to think about it is that we have that execution of the Enclave. And we can break that up into individual steps and then just count the steps. And hence, have a deterministic, eigen-alive timing channel. So in other words, we have an Oracle that tells you where all zero bytes are in the Enclave. I don't know if that's useful, actually, Dave. So it turns out it is. I mean, some people who might be into exploitation already know that it's good to know whether zero is somewhere in memory or not. And we now do one example. We break AES and I, which is the hardware acceleration of Intel process for AI. So finally, that actually operates only on registers. And Joe just said he can do that on pointers, on memory. There's another trick that comes into play here. So whenever the Enclave is interrupted, it will store its current registers state somewhere to memory called the SSA frame. So we can actually interrupt the Enclave, make it write its register to SSA memory, and then we can run the zero byte Oracle on the SSA memory. And what we figure out is where zero is, or if there's any zero in the AES state. So I don't want to go into the gory details of AES. But what we basically do is we find whenever there's zero in the last in the state before the last round of AES, and then that zero will go down through the S-box, will be x or to a key byte, and then that will give us a ciphertext. But we actually know the ciphertext byte. So we can go backwards. We can compute from the zero up to here and from here to this x or. And that way, we can compute directly one key byte. So we repeat that whole thing 16 times until we have found zero in every byte of this state before the last round. And that way, we get the whole final round key. And for those that know AES, if you have one round key, you have the whole key in it. So you get like the original key. You can go backwards. So sounds complicated, but it's actually a very fast attack when you see it running. So here is SGX step doing this attack. And as you can see within a couple of seconds, and maybe 520 invocations of AES here, we get the full key. So that's actually quite impressive, especially because one of the points in AES and I is that you don't put anything in memory, but there's this interaction with SGX, which is kind of like allows you to put stuff into memory. So I want to wrap up here. We have found various other attacks. So both in research code and in production codes, such as the Intel SDK and the Microsoft SDK, and they basically go across the whole range of vulnerabilities that we have often seen already from user to kernel research. But there are also some interesting new kind of vulnerabilities due to some of the aspects we explained. There was also a problem with O-calls, that is when the enclave calls into untrusted codes, so that is used when you want to, for instance, emulate system calls and so on. And if you return some kind of like a wrong result here, you could again go out of bounds. And they were actually quite widespread. And then finally, we also found some issues with padding, with leakage in the padding. I don't want to go into details. I think we have learned a lesson here that we also know from the real world. And that is important to wash your hands. So it's also important to sanitize, enclave state, to check pointers and so on. So that is kind of one of the takeaway messages, really, is that to build enclave securely, yes, you need to fix all the hardware issues, but you also need to write safe code. And for enclaves, that means you have to do proper ABI and API sanitizations. And that's quite a difficult task, actually, as we've seen, I think, in that presentation. There's quite a large attack surface due to the attack model, especially of Intel SGX, where you can interrupt after every instruction and so on. And I think from a research perspective, there's really a need for a more principled approach than just bug hunting. If you want, maybe we can learn something from the user-to-carnal analogy, which I invoked, I think, a couple of times. So we can learn kind of like what an enclave should do from what we know about what a kernel should do. But there are quite important differences also that need to be taken account. So I think, as you said, all our code is open source, so you can find that on the below GitHub links. And you can, of course, ask also questions after you have watched this talk. So thank you very much. Hello. So back again, here are the questions. Hello to see you live. We have no questions yet, so you can put up questions in the IRC below if you have questions. And on the other hand, oh, let me close this up. So I'll ask you some questions. How did you come about this topic and how did you meet? Well, that's actually interesting. I think this research has been building up over the years. And there is some. So I think some of the vulnerabilities from our initial paper, I actually already started in my master thesis to sort of see and collect. And we didn't really see the big picture until I think I met David and his colleagues from Birmingham at an event in London, the RISE conference. And then we started to collaborate on this and to look at this a bit more systematic. So I started with this whole list of vulnerabilities. And then with David, we kind of made it into a more systematic analysis. And that was sort of a Pandora's box, I dare to say. From that moment on, these kind of same errors keeping repeated. And then also Fritz, who recently joined our team in Leuven, started working together with us on more of this low level CPU state. And that's Pandora's box in itself, I would say, especially one of the lessons, as we say there, that x86 is extremely complex. And turns out that almost all of that complexity, I would say, can be abused potentially by adversaries. So it's more like a fractal in a fractal in a fractal. You're opening a box and you're getting more and more of questions out of that. In a way, I think, yes, I think it's fair to say this research is not the final answer to this. But it's rather an attempt to give a systematic way of looking at a poorly never ending attacker defender race. So there is a question from the internet. So are there any other circumstances where AES minus NE is writing its registers into memory, or is this exclusive to SGX? Should I repeat? I do not understand the question either. So I think the question is that this AES attack that David presented depends on, of course, having a memory disclosure attack to read the register content. And we pull that off using SGX step to forcibly write the register content into memory. So that is definitely SGX specific. However, I would say one of the lessons from, let's say, the past five years of SGX research is that often these things generalize beyond SGX. And at least the general concept of, let's say, the insight that CPU registers end up in memory one way or another sooner or later. I think that also applies to operating systems. If you somehow can force an operating system to context it between two applications, it will also have to dump the register content temporarily in memory. So if you would have something similar like what we have in an operating system kernel, you would potentially mount a similar attack. But maybe David wants to say something about operating systems there as well. No, not really. I think one thing that helps with SGX is that you have very precise control, as you explained with the interrupts and stuff, because you root outside the enclave. So you can single step, essentially, the whole enclave whereas interrupting the operating system at exactly repeatedly, at exactly the point you want or some other process or so tends to be probably harder just by design. But of course, on a context switch, CPU has to save somewhere its register set, and then it will end up in memory in some situations, probably not as controlled as it is for SGX. So there is the question, what about other CPU architectures other than Intel? Did you test those? So maybe I can go into this. So well, interest SGX is the, let's say, largest one with the largest software base and the most enclave shooting runtimes that is also that we could look at. But there are, of course, some others. So for example, we have this internal TE that we developed at SanQus. Some years ago, it's called SanQus. And of course, for these, there are similar issues. So you always need the software layer to interact, to enter the enclave and to access the enclave. And I think you and David in the earlier work also found issues in our TE. So it's not just Intel and related projects that mess up, there, of course. But what we definitely found is that it's easier to think of all edge cases for simpler designs like RISC-5 or simpler RISC designs than for this complex X86 architecture. So right now, there are not that many besides Intel SGX. So they have the advantage and disadvantage of being the first widely deployed, let's say. But I think as soon as others start to grow out and simpler designs start to be more common, I think we will see this that it's easier to fix all edge cases for simpler designs. OK, so what is a reasonable alternative to TE? Or is there any? You do you want to take that or should I say what? Well, we can probably both give our perspective. So I think, well, the question to start with, of course, is do we need an alternative? Or do we need to find more systematic ways to sanitize the software layers? That's, I think, one part of the answer here, that we don't have to necessarily throw away TEs because we have problems with them. We can also look at how to solve those problems. But apart from that, there is some exciting research that maybe David also wants to say a bit more about, for instance, on capabilities. That's in a way not so different than TE is necessary. But when you have hardware support for capabilities, like the Cherry Project in Cambridge, which essentially associates metadata to a pointer, metadata like permission checks, then you could, at least for a subclass of the issues we talked about, pointer poisoning attacks, you could natively leakage those with hardware support. But it's a very high level idea. Maybe David wants to say something. Yeah, so I think like an alternative to TE is, whenever you want to partition your system into parts, which is, I think, a good idea. And everybody is now doing that also in there, how we build online services and stuff. So TEs are one system that we have become quite used to from mobile phones or from maybe even from something like a banking card or so, which is also like a protected environment for a very simple job. But the problem then starts when you throw a lot of functionality into the TE. As we saw the trusted code base becomes more and more complex and you get traditional bugs. So think like, yeah, it's really the question if you need an alternative or a better way of approaching it, how your partition software. And as you mentioned, there are some other things you can do architecturally so you can change the way we or extend the way we build architectures, for instance, with this capabilities and then start to isolate components, for instance, in one software project, say in your web server, you isolate the TLS stack or something like this. And also thanks for the people noticing the secret password here. So obviously only for decoration purposes to give the people something to watch. So but it's not fundamentally broken, is it? SGX. Yeah, no, SGX TE. I mean, TE's are the menu of them. I think like you cannot say fundamentally broken for it. But for SGX it has. The question I had was specifically for SGX at that point, because Signal uses it, mobile coin, cryptocurrency uses it and so on and so forth. Is that fundamentally broken or would you rather say? So I guess it depends what you call fundamentally. So there has been in the past we have worked also on what I would say full breaches of SGX. But they have been fixed. And it's actually quite a beautiful instance of where research can have short term industry impact. So you find a vulnerability, then the vendor has to devise a fix that they are often not reveal. And they often work around to the problem. And then later, because we are talking of course about hardware roots of trust, so then you need no processes to really get a fundamental fix for the problem. And then you have temporary work arounds. So I would say, for instance, a company like Signal using SGX, if they. So it does not give you security by default. You need to think about the software. That's what you focused on in this talk. You also need to think about all of the hardware microcode patches and or new processors to take care of all the known vulnerabilities. And of course the question always remains, are there vulnerabilities that we don't know yet? That's with any secure system, I guess. But maybe also David wants to say something about some of his latest work there. That's a bit interesting. Yeah, so I think what you said, or my answer to this question would be, it depends on your threat model, really. So some people use SGX as a way to kind of like remove the trust in the cloud providers. So you say like as in Signal or so, I move all this functionality that is hosted maybe on some cloud provider into an SGX enclave. And then I don't have to trust the cloud provider anymore because SGX also has some form of protection against physical access. But recently we actually, we published another attack which shows that if you have hardware access to an SGX processor, you can inject faults into the processor by playing with the undervolting interface with hardware access. So you really solder to the main board to a couple of wires on the bus to the voltage regulator. And then you can do voltage glitching as some people might know from other embedded contexts. And that way then you can flip bits essentially in the enclave and of course do all kinds of, kind of like inject all kinds of evil effects that then can be used further to get keys out or maybe hijack control flow or something. So it depends on your threat model. I wouldn't say still that SGX is completely pointless. It's, I think better than not having it at all, but it definitely cannot, you cannot have like complete protection against somebody who has physical access to your server. So I have to close this talk. It's a bummer. I would ask all that questions that are flowing here. But one very, very fast answer please. What is that with a password in your background? I explained it. It's of course like just a joke. So I'll say it again because some people seem to have taken it seriously. So it was such an empty whiteboard. So I put a password there. Unfortunately, it's not fully visible in the, in the stream. Okay. So I thank you, Jo van Boek, Fritz Alder, David Oswald. Thank you for having that nice talk. And now we make the transition to the Herod New Show. Thank you.
 So, for the next talk, I have Jo van Bulk and Fritz Alder from the University of Löwen  in Belgium and David Oswald, a professor for cybersecurity in Birmingham.  They are here to talk about the trusted execution environment you probably know from Intel and so on.  And you should probably not trust it all the way because it's software and it has its flaws.  And so they're talking about ramming enclave gates, which is always good,  a systematic vulnerability assessment of TE shielding runtimes.  Please go on with the talk.  Hi everyone, welcome to our talk.  So I'm Jo from the E-Mate Disonet Research Group at Kea Löwen.  And today joining me are Fritz also from Löwen and David from the University of Birmingham.  And we have this very exciting topic to talk about ramming enclave gates.  But before we dive into that, I think most of you will not know what are enclaves,  let alone what are these TEs.  So let me first start with some analogy.  So enclaves are essentially sort of a secure fortress in the processor in the CPU.  And so it's an encrypted memory region that is exclusively accessible from the inside.  And what we know from the last history of fortress attacks and defenses, of course,  is that when you cannot take a fortress because the walls are high and strong,  you typically aim for the gates, right?  That's the weakest point in any fortress defense.  And that's exactly the idea of this research.  So it turns out to apply to enclaves as well.  And we have been ramming the enclave gate.  We have been attacking the input-output interface of the enclave.  So a very simple idea, but very drastic consequences, I dare to say.  So this is sort of the summary of our research with over 40 interface sanitization vulnerabilities  that we found in over eight widely used open source enclave projects.  So we will go a bit into detail over that in the rest of the slides.  Also, a nice thing to say here is that this resulted in two academic papers to date,  over seven CVEs, and altogether quite some responsible disclosure lengthy and viral periods.  OK, so I guess we should talk about why we need such enclave fortresses anyway.  So if you look at traditional kind of like operating system or computer architecture,  you have a very large trusted computing base.  So for instance, on the laptops that you most likely use to watch this talk,  you trust the kernel, you trust maybe a hypervisor if you have,  and the whole hardware under the system, so CPU, memory,  maybe hard drive, trusted platform module, and the likes.  So actually the problem is here with such a large TCB,  trusted computing base, you can also have vulnerabilities basically everywhere,  and also malware hiding in all these parts.  So the idea of this enclave execution is, as we find for instance in Intel SGX,  which is built into most recent Intel processors,  is that you take most of the software stack between an actual application,  here the enclave app, and the actual CPU out of the TCB.  So now you only trust really the CPU, and of course you trust your own code,  but you don't have to trust the OS anymore,  and SGX for instance promises to protect against an attacker who has achieved a route  in the operating system, and even depending on who you ask against,  for instance a malicious cloud provider,  so imagine you run your application on the cloud,  and then you can still run your code in a trusted way,  with hardware level isolation, and you have attestation and so on,  and you no longer really have to trust even the administrator.  So the problem is of course that attack surface remains,  so previous attacks and some of them I think will also be presented  at this remote congress this year,  have targeted vulnerabilities in the micro architecture of the CPU.  So you are attacking basically the hardware level,  so you have foreshadow, you have micro architecture data sampling,  specter and LVI and the likes,  but what less attention has been paid to,  and what we'll talk about more in this presentation,  is the software level inside the enclave,  which I hinted at, that there's some software that you trust,  but now we look in more detail into what actually is in such an enclave  from the software side.  So can an attacker exploit any classical software vulnerabilities  in the enclave?  Yes, David, that's quite an interesting approach, right?  Let's aim for the software, so we have to understand  what is the software landscape out there for these SGX enclaves  and DEs in general.  So that's what we did, we started with an analysis  and you see some screenshots here,  this is actually a growing open source ecosystem,  many of these run times, library opening system SDKs.  And before we dive into the details,  I want to stand still with what is the common factor  that all of them share, right?  What is kind of the idea of these enclave development environments?  So here, what any DE to set execution environment  gives you is this notion of a secure enclave oasis  in a hostile environment, right?  And you can do secure computations in that green box  while the outside world is burning.  As with any defense mechanism, as I said earlier,  the devil is in the details and typically at the gate, right?  So how do you mediate between that undisturbed world  where the desert is on fire and the secure oasis in the enclave?  And the intuition here is that you need some sort  of intermediary software layer, which  what we call a shielding runtime.  So it kind of makes a secure bridge  to go from the interstitled to the enclave and back.  And that's what we are interested in, right?  To see what kind of security checks you need to do there.  So it's quite a beautiful picture.  You have on the right the fertile enclave,  and on the left the hostile desert.  And we make this secure bridge in between.  And what we are interested in is what if it goes wrong?  What if your bridge itself is flawed?  So to answer that question, we look  at that yellow box and we ask what kind of sanitizations,  what kind of security checks do you  need to apply when you go from the outside to the inside  and back from the inside to the outside?  And one of the key contributions that we have built up  in the past two years of this research, I think,  is that the yellow box can be subdivided  into two smaller subsequent layers.  And the first one is this ABI application binary interface,  very low level CPU state.  And the second one is what we call API application  programming interface.  So that's the kind of state that's already  visible at the programming language.  Then the remainder of this presentation,  we will kind of guide you through some relevant vulnerabilities  at both these layers to give you an understanding of what  this means.  So first Fritz will guide you to the exciting low level  landscape of the ABI.  Yeah, exactly.  And you just said it's the CPU state,  and it's the application binary interface.  But let's take a look at what this means, actually.  So it means basically that the attacker controls the CPU  register contents.  And we do have to proceed.  And that on every enclave entry or on every enclave exit,  we need to perform some tasks so that the enclave and the trust  runtime have some well initialized CPU state.  And the compiler can work with the calling conventions  that it expects.  So these are basically the key part.  We need to initialize the CPU registers  when entering the enclave and scrubbing them  when we exit the enclave.  So we can't just assume anything  that the attacker gives us as a given.  We have to initialize it to something proper.  And we looked at multiple TTE runtimes and then  multiple TEs.  And we found a lot of vulnerabilities in this ABI layer.  And one key insight of this analysis  is basically that a lot of these vulnerabilities  happen on complex instruction set processors.  So on CISC processors.  And basically on the InternetGX TTE.  We also looked at some RISC processors.  And of course, it's not representative.  But it's immediately visible that a complex x86 ABI  seems to have a way higher, larger tech surface  than the simpler RISC designs.  So let's take a look at one example of this more complex  design.  So for example, there's the x86 string instructions  that are controlled by the direction flag.  So there's a special x86 rep instruction  that basically allows you to perform stream memory  operations.  So if you do like a memset on a buffer,  this will be compiled into the rep string operation  instruction.  And the idea here is basically that the buffer is read  from left to right and well, written over by memset.  But this direction flag also allows  you to go through it from right to left, so backwards.  Let's not think about why this was a good idea  or why this is needed.  But definitely it is possible to just set the direction flag  to one and run this buffer backwards.  And what we found out is that the system VABI actually  says that this must be clear or set to forward on function  entry and return.  And that compilers expect this to happen.  So let's take a look at this when we do this in our enclave.  So in our enclave, when we in our trusted application  perform this memset on our buffer,  on normal entry with the normal direction flag,  this just means that we walk this buffer from front to back.  So you can see here, it just runs correctly from front to back.  But now if the attacker enters the enclave with the direct  direction flag set to one, so it sets to run backwards,  this now means that from the start of our buffer,  so from where the pointer points right now,  you can now see it actually runs backwards.  So that's the problem.  And that's definitely something that we don't want  in our trust applications.  Because, well, as you can think, it  allows you to override keys that are in the memory  locations that you can go backwards.  It allows you to read out things.  That's definitely not something that is useful.  And when we reported this, this actually got a nice CD  assigned with the base core high, as you can see here  in the next slide.  And, well, you may think, OK, well, that's one instance.  And you just have to think of all the flex  to sanitize and all the flex to check.  But wait, of course, there's always more.  So as we found out, there's actually  the floating point units, which comes with a whole lot  of other registers and a whole lot of other things to exploit.  And I will spare you all the details.  But just for this presentation, just know  that there is an older x87FPU and new SSE that  does vector float.  This is vector floating point operations.  So there's the FPU control word and the MXCSR register  for these newer instructions.  And this x87FPU is older, but it's still used, for example,  for extended precision, like long double variables.  So old and new doesn't really apply here  because both are still relevant.  And that's kind of the thing with x86 and x87 here,  that old archaic things that you could say are outdated  are still relevant or are still used nowadays.  And again, if you look at the system VABI now,  we saw that these control bits are coalescated.  So they are preserved across function codes.  And the idea here is, which to some degree holds merit,  is that these are some global states that you can set.  And they are transferred within one application.  So one application can set some global state  and keeps the state across all its usage.  But the problem here, as you can see here,  then is our application or Enclave  is basically one application.  And we don't want our attacker to have control over the global  state within our trusted application.  So what happens if PUS settings are preserved across codes?  Well, for a normal user, let's say  we just do some calculation inside the Enclave,  like 2.1 times 3.4, which just nicely calculates to a 7.14  long double.  That's nice.  But what happens if the attacker now enters the Enclave  with some corrupt precision and rounding  modes for the FPU?  Well, then we actually get another result.  So we get distorted results with the lower precision  and different rounding modes.  So it's actually rounding down here,  whenever it exceeds the precision.  And this is something we don't want.  So this is something where the developer expects  certain precision or a long double precision,  but the attacker could actually just reduce it  to a very short precision.  And we reported this, and we actually found this issue also  in Microsoft Open Enclave.  That's why it's marked as not exploitable here.  But what we found interesting is that the Intel SGX SDK,  which was vulnerable, patched this  with an X restore instruction, which completely restores  the extended state to a known value.  While Open Enclave only restores the specific register  that was affected, the load MXC SR instruction.  And so let's just skip over the next few slides here,  because I just want to give you the idea  that this was not enough.  So we found out that even if you restore this specific register,  there's still another data register  that you can just mark as in use before entering the Enclave,  and with which the attacker can make  that any floating point calculation  results in another number.  And this is silent, so this is not programming language  specific, this is not developer specific.  This is a silent ABI issue that the calculations are just  not a number.  So we also reported this.  And now, thankfully, all Enclave runtime  uses full X restore instruction to fully  restore this extended state.  So it took two CDs, but now luckily,  they all perform this nice full restore.  So I don't want to go into the full details of our use cases  now or of our case studies that we did now.  So let me just give you the ideas of these case studies.  So we looked at these issues and wanted  to look into whether they just feel difficult  or whether they are a bet.  And we found that we can use overflows as a side channel  to deduce secrets.  So for example, the attacker could  use this register to unmask exceptions  that inside the Enclave are then triggered  by some input dependent multiplication.  And we found out that these side channels,  if you have some input dependent multiplication,  can actually be used in the Enclave  to perform a binary search on this input space.  And we can actually retrieve this multiplication secret  with a deterministic number of steps.  So even though we adjust it like a single mask,  we flip, we can actually retrieve the secret  with deterministic steps.  And just so that you know there's more you can do,  we can also do machine learning in the Enclave.  So if you all said it nicely, you  can run it inside the TE, inside the cloud.  And that's great for machine learning, right?  So let's do hand written digit recognition.  And if you look at just the model that we look at,  we just have two users where one user pushes  some machine learning model and the other user pushes  some input.  And everything is protected with Enclave, right?  So everything is secure.  But we actually found out that we  can poison these FPU registers and degrade  the performance of this machine learning down  from all digits were predicted correctly to just 8%  of digits were correctly.  And actually, all digits were just predicted the same number.  And this basically made this machine learning model useless.  There's more we did.  So we can also attack Blender with image differences,  slight differences between Blender images.  But that's just for you to see that it's small.  But it's a tricky thing and intricate  that can go wrong very fast on the ABI level once you play  around with it.  So this is about the CPU state.  And now we will talk more about the application programming  interface that I think more of you will be comfortable with.  Yeah, we take, thank you Fritz.  We take quite a simple example.  So let's assume that we actually load the standard Unix binary  into such an Enclave.  And there are frameworks that can do that, such as a Graphina.  So and what I want to illustrate with that example  is that it's actually very important to check where  a point has come from.  Because the Enclave kind of partitions the memory  into untrusted memory and Enclave memory.  And they live in a shared address space.  So the problem here is as follows.  Let's assume we have an echo binary that just prints an input.  And we give it as an argument string.  And that normally, when everything is fine now,  points to some string, let's say,  hello world, which is located in the untrusted memory.  So if everything runs as it should,  this Enclave will run, will get the pointer to untrusted memory,  and will just print that string.  But the problem is now actually the Enclave  has access also to its own trusted memory.  So if you don't check this pointer and the attacker passes  a pointer to the secret that might live in Enclave memory,  what will happen?  Well, the Enclave will fetch it from there  and will just print it.  So suddenly you have turned this kind of like into a memory  disclosure vulnerability.  And we can see that in action here for the framework named  Graphine that I mentioned.  So we have a very simple hello world binary.  And we run it with a couple of command line arguments.  And now in on the untrusted side,  we actually change a memory address  to point into Enclave memory.  And as you can see, normally it should print here test.  But actually it prints a super secret Enclave string  that lift inside the memory space of the Enclave.  So these kind of vulnerabilities are quite well known  from user to kernel research and from other instances.  And they're called confused deputies.  So the deputies kind of like has a gun,  can read the Enclave memory and suddenly  then does something which is not supposed to do  because it didn't really check where the memory should  belong or not.  So I think this vulnerability seems  to be quite trivial to solve.  You simply check all the time where pointers come from.  But as you will tell, it's often not quite that easy.  Yes, David, that's quite insightful.  We should check all of the pointers.  So that's what we did.  We checked all of the pointer checks.  And we noticed that Intel has a very interesting kind  of algorithm to check these things.  Of course, the Intel code is high quality.  They checked all of the pointers.  But you have to do something special for strings.  And we're talking here the C programming language.  So strings are null terminated.  They end with a null byte.  And you can use the function sdln string  length to compute the length of the string.  And let's see how they check whether your string lights  completely outside of Enclave memory.  So the first step is you compute the length  of the interested string.  And then you check whether the string from start to end  lights completely outside of the Enclave.  That sounds legit, right?  And you reject the string.  So this works beautifully.  Let's see however how it behaves when  we pass on a legal string.  So we are not going to pass the string  hello world outside of the Enclave.  But we pass some string secret one  that lies within the Enclave.  So the first step will be that the Enclave starts  computing the length of that string that  lies within the Enclave.  And that sounds already fishy.  But then luckily everything comes OK,  because then it will detect that this actually should never  have been done and that the string lies inside the Enclave.  So it will reject the e-cals, or the call into the Enclave.  So that's fine.  But some of you who know side channels  know that this is exciting, right?  Because the Enclave did some computation  it was never supposed to do.  And the length of that computation  depends on the amount of non-zero bytes within the Enclave.  So what we have here is a side channel  where the Enclave will always return false.  But the time it takes to return false  depends on the amount of zero bytes inside that secret Enclave  memory blob.  So that's what we found.  We were excited.  And we said, OK, that's a simple timing channel.  Let's go to that.  So we did that.  And you can see a graph here.  And it turns out it's not as easy as it seems, right?  So I can tell you that the blue one is for a string of length  one and the red one is for a string of length two.  But there is no way you can see that from that graph.  Because x86 processors are lightning fast  so that one single increment instruction is completely  dissolves into the pipeline.  You will not see that by measuring execution time.  So we need something different.  And while we are smart, so we read papers.  And in literature, one of the very common attacks in SJX  is also something that Intel describes here.  You can see which memory pages 4K memory blocks are being  accessed while the Enclave executes  because you control the operating system  and the paging machinery in there.  So that's what we tried to do.  And we thought this is a nice side channel.  And we were there sketching our head looking at that code,  a very simple for loop that fits entirely within one page  and a very short string that fits entirely within one page.  So just having access to 4K memory regions  is not going to help us here, right?  Because vote the code and the data fit on a single page.  So this is essentially what we call  the temporal resolution of the side channel.  This is not accurate enough.  So we need another trick.  And well, here we have been working  on quite an exciting framework.  It uses interrupts.  And it's called SGX Step.  So it's a completely open source framework on Hitup.  And what it allows you to do essentially  is to execute an Enclave one step at a time.  Hence the name.  So it allows you to interleave the execution of the Enclave  with attacker code after every single instruction.  And the way we pulled it off is highly technical.  We have this Linux kernel driver and a little library  operating system running in user space.  But that's a bit out of scope.  The matter is that we can interrupt an Enclave  after every single instruction.  And then let's see what we can do with that.  So what we essentially can do here  is to execute that for loop with all these x86 increment  instructions one at a time.  And after every interrupt, we can simply  check whether the Enclave accessed the string residing  at our target as memory location.  Another way to think about it is that we  have that execution of the Enclave.  And we can break that up into individual steps  and then just count the steps.  And hence, have a deterministic,  eigen-alive timing channel.  So in other words, we have an Oracle that tells you  where all zero bytes are in the Enclave.  I don't know if that's useful, actually, Dave.  So it turns out it is.  I mean, some people who might be into exploitation  already know that it's good to know whether zero is somewhere  in memory or not.  And we now do one example.  We break AES and I, which is the hardware acceleration  of Intel process for AI.  So finally, that actually operates only on registers.  And Joe just said he can do that on pointers, on memory.  There's another trick that comes into play here.  So whenever the Enclave is interrupted,  it will store its current registers  state somewhere to memory called the SSA frame.  So we can actually interrupt the Enclave,  make it write its register to SSA memory,  and then we can run the zero byte Oracle on the SSA memory.  And what we figure out is where zero is,  or if there's any zero in the AES state.  So I don't want to go into the gory details of AES.  But what we basically do is we find whenever  there's zero in the last in the state  before the last round of AES, and then that zero will go down  through the S-box, will be x or to a key byte,  and then that will give us a ciphertext.  But we actually know the ciphertext byte.  So we can go backwards.  We can compute from the zero up to here  and from here to this x or.  And that way, we can compute directly one key byte.  So we repeat that whole thing 16 times  until we have found zero in every byte of this state  before the last round.  And that way, we get the whole final round key.  And for those that know AES, if you have one round key,  you have the whole key in it.  So you get like the original key.  You can go backwards.  So sounds complicated, but it's actually a very fast attack  when you see it running.  So here is SGX step doing this attack.  And as you can see within a couple of seconds,  and maybe 520 invocations of AES here,  we get the full key.  So that's actually quite impressive, especially  because one of the points in AES and I  is that you don't put anything in memory,  but there's this interaction with SGX, which  is kind of like allows you to put stuff into memory.  So I want to wrap up here.  We have found various other attacks.  So both in research code and in production codes,  such as the Intel SDK and the Microsoft SDK,  and they basically go across the whole range of vulnerabilities  that we have often seen already from user to kernel research.  But there are also some interesting new kind of vulnerabilities  due to some of the aspects we explained.  There was also a problem with O-calls,  that is when the enclave calls into untrusted codes,  so that is used when you want to, for instance,  emulate system calls and so on.  And if you return some kind of like a wrong result here,  you could again go out of bounds.  And they were actually quite widespread.  And then finally, we also found some issues with padding,  with leakage in the padding.  I don't want to go into details.  I think we have learned a lesson here  that we also know from the real world.  And that is important to wash your hands.  So it's also important to sanitize,  enclave state, to check pointers and so on.  So that is kind of one of the takeaway messages, really,  is that to build enclave securely,  yes, you need to fix all the hardware issues,  but you also need to write safe code.  And for enclaves, that means you have to do proper ABI  and API sanitizations.  And that's quite a difficult task, actually,  as we've seen, I think, in that presentation.  There's quite a large attack surface  due to the attack model, especially of Intel SGX,  where you can interrupt after every instruction and so on.  And I think from a research perspective,  there's really a need for a more principled approach  than just bug hunting.  If you want, maybe we can learn something  from the user-to-carnal analogy, which I invoked,  I think, a couple of times.  So we can learn kind of like what an enclave should do  from what we know about what a kernel should do.  But there are quite important differences also  that need to be taken account.  So I think, as you said, all our code is open source,  so you can find that on the below GitHub links.  And you can, of course, ask also questions  after you have watched this talk.  So thank you very much.  Hello.  So back again, here are the questions.  Hello to see you live.  We have no questions yet, so you can put up questions  in the IRC below if you have questions.  And on the other hand, oh, let me close this up.  So I'll ask you some questions.  How did you come about this topic and how did you meet?  Well, that's actually interesting.  I think this research has been building up over the years.  And there is some.  So I think some of the vulnerabilities  from our initial paper, I actually  already started in my master thesis  to sort of see and collect.  And we didn't really see the big picture  until I think I met David and his colleagues from Birmingham  at an event in London, the RISE conference.  And then we started to collaborate on this  and to look at this a bit more systematic.  So I started with this whole list of vulnerabilities.  And then with David, we kind of made it  into a more systematic analysis.  And that was sort of a Pandora's box, I dare to say.  From that moment on, these kind of same errors  keeping repeated.  And then also Fritz, who recently joined our team in Leuven,  started working together with us on more of this low level CPU  state.  And that's Pandora's box in itself, I would say,  especially one of the lessons, as we say there,  that x86 is extremely complex.  And turns out that almost all of that complexity, I would say,  can be abused potentially by adversaries.  So it's more like a fractal in a fractal in a fractal.  You're opening a box and you're getting more and more  of questions out of that.  In a way, I think, yes, I think it's fair to say  this research is not the final answer to this.  But it's rather an attempt to give a systematic way  of looking at a poorly never ending attacker defender race.  So there is a question from the internet.  So are there any other circumstances  where AES minus NE is writing its registers into memory,  or is this exclusive to SGX?  Should I repeat?  I do not understand the question either.  So I think the question is that this AES attack that David  presented depends on, of course, having a memory disclosure  attack to read the register content.  And we pull that off using SGX step  to forcibly write the register content into memory.  So that is definitely SGX specific.  However, I would say one of the lessons from, let's say,  the past five years of SGX research  is that often these things generalize beyond SGX.  And at least the general concept of, let's say, the insight  that CPU registers end up in memory one way or another  sooner or later.  I think that also applies to operating systems.  If you somehow can force an operating system  to context it between two applications,  it will also have to dump the register content temporarily  in memory.  So if you would have something similar like what  we have in an operating system kernel,  you would potentially mount a similar attack.  But maybe David wants to say something about operating systems  there as well.  No, not really.  I think one thing that helps with SGX  is that you have very precise control,  as you explained with the interrupts and stuff,  because you root outside the enclave.  So you can single step, essentially, the whole enclave  whereas interrupting the operating system  at exactly repeatedly, at exactly the point you want  or some other process or so tends to be probably harder  just by design.  But of course, on a context switch,  CPU has to save somewhere its register set,  and then it will end up in memory in some situations,  probably not as controlled as it is for SGX.  So there is the question, what about other CPU architectures  other than Intel?  Did you test those?  So maybe I can go into this.  So well, interest SGX is the, let's say,  largest one with the largest software base  and the most enclave shooting runtimes that is also  that we could look at.  But there are, of course, some others.  So for example, we have this internal TE  that we developed at SanQus.  Some years ago, it's called SanQus.  And of course, for these, there are similar issues.  So you always need the software layer to interact,  to enter the enclave and to access the enclave.  And I think you and David in the earlier work  also found issues in our TE.  So it's not just Intel and related projects that mess up,  there, of course.  But what we definitely found is that it's easier  to think of all edge cases for simpler designs like RISC-5  or simpler RISC designs than for this complex X86 architecture.  So right now, there are not that many besides Intel SGX.  So they have the advantage and disadvantage  of being the first widely deployed, let's say.  But I think as soon as others start to grow out  and simpler designs start to be more common,  I think we will see this that it's easier  to fix all edge cases for simpler designs.  OK, so what is a reasonable alternative to TE?  Or is there any?  You do you want to take that or should I say what?  Well, we can probably both give our perspective.  So I think, well, the question to start with, of course,  is do we need an alternative?  Or do we need to find more systematic ways  to sanitize the software layers?  That's, I think, one part of the answer here,  that we don't have to necessarily throw away  TEs because we have problems with them.  We can also look at how to solve those problems.  But apart from that, there is some exciting research  that maybe David also wants to say a bit more about,  for instance, on capabilities.  That's in a way not so different than TE is necessary.  But when you have hardware support for capabilities,  like the Cherry Project in Cambridge, which essentially  associates metadata to a pointer,  metadata like permission checks, then you could,  at least for a subclass of the issues we talked about,  pointer poisoning attacks, you could natively  leakage those with hardware support.  But it's a very high level idea.  Maybe David wants to say something.  Yeah, so I think like an alternative to TE is,  whenever you want to partition your system into parts,  which is, I think, a good idea.  And everybody is now doing that also in there,  how we build online services and stuff.  So TEs are one system that we have become quite used to  from mobile phones or from maybe even from something  like a banking card or so, which is also  like a protected environment for a very simple job.  But the problem then starts when you throw a lot of  functionality into the TE.  As we saw the trusted code base becomes more and more  complex and you get traditional bugs.  So think like, yeah, it's really the question  if you need an alternative or a better way of approaching it,  how your partition software.  And as you mentioned, there are some other things you can do  architecturally so you can change the way we or extend the  way we build architectures, for instance, with this  capabilities and then start to isolate components, for  instance, in one software project, say in your web  server, you isolate the TLS stack or something like this.  And also thanks for the people noticing the secret  password here.  So obviously only for decoration purposes to give  the people something to watch.  So but it's not fundamentally broken, is it?  SGX.  Yeah, no, SGX TE.  I mean, TE's are the menu of them.  I think like you cannot say fundamentally broken for it.  But for SGX it has.  The question I had was specifically for SGX at that  point, because Signal uses it, mobile coin, cryptocurrency  uses it and so on and so forth.  Is that fundamentally broken or would you rather say?  So I guess it depends what you call fundamentally.  So there has been in the past we have worked also on what I  would say full breaches of SGX.  But they have been fixed.  And it's actually quite a beautiful instance of where  research can have short term industry impact.  So you find a vulnerability, then the vendor has to  devise a fix that they are often not reveal.  And they often work around to the problem.  And then later, because we are talking of course about  hardware roots of trust, so then you need no processes to  really get a fundamental fix for the problem.  And then you have temporary work arounds.  So I would say, for instance, a company like  Signal using SGX, if they.  So it does not give you security by default.  You need to think about the software.  That's what you focused on in this talk.  You also need to think about all of the  hardware microcode patches and or new processors to take  care of all the known vulnerabilities.  And of course the question always remains, are there  vulnerabilities that we don't know yet?  That's with any secure system, I guess.  But maybe also David wants to say something about some of  his latest work there.  That's a bit interesting.  Yeah, so I think what you said, or my answer to this  question would be, it depends on your threat model, really.  So some people use SGX as a way to kind of like remove the  trust in the cloud providers.  So you say like as in Signal or so, I move all this  functionality that is hosted maybe on some cloud provider  into an SGX enclave.  And then I don't have to trust the cloud provider anymore  because SGX also has some form of protection against  physical access.  But recently we actually, we published another attack which  shows that if you have hardware access to an SGX  processor, you can inject faults into the processor by  playing with the undervolting interface with hardware access.  So you really solder to the main board to a couple of wires  on the bus to the voltage regulator.  And then you can do voltage glitching as some people might  know from other embedded contexts.  And that way then you can flip bits essentially in the  enclave and of course do all kinds of, kind of like inject  all kinds of evil effects that then can be used further to  get keys out or maybe hijack control flow or something.  So it depends on your threat model.  I wouldn't say still that SGX is completely pointless.  It's, I think better than not having it at all, but it  definitely cannot, you cannot have like complete protection  against somebody who has physical access to your server.  So I have to close this talk.  It's a bummer.  I would ask all that questions that are flowing here.  But one very, very fast answer please.  What is that with a password in your background?  I explained it.  It's of course like just a joke.  So I'll say it again because some people seem to have taken it  seriously.  So it was such an empty whiteboard.  So I put a password there.  Unfortunately, it's not fully visible in the, in the stream.  Okay.  So I thank you, Jo van Boek, Fritz Alder, David Oswald.  Thank you for having that nice talk.  And now we make the transition to the Herod New Show.  Thank you.
rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_0_59.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_60_167.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_168_227.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_228_275.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_276_431.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_432_2663.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_2664_3095.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_3096_4031.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_4032_5423.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_5424_8327.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_8328_9311.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_9312_10595.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_10596_12203.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_12204_17183.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_17184_18959.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_18960_19415.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_19416_19511.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_19512_21131.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_21132_21803.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_21804_23231.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_23232_24491.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_24492_25931.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_25932_27023.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_27024_27779.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_27780_28427.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_28428_28823.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_28824_29063.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_29064_29387.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_29388_29951.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_29952_32279.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_32280_36719.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_36720_36767.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_36768_37391.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_37392_37535.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_37536_37931.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_37932_38651.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_38652_38843.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_38844_39683.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_39684_40499.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_40500_41207.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_41208_43643.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_43644_44363.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_44364_45683.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_45684_46283.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_46284_48815.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_48816_50363.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_50364_50579.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_50580_51227.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_51228_51467.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_51468_52151.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_52152_53459.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_53460_53603.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_53604_54695.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_54696_54995.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_54996_56423.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_56424_56807.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_56808_57119.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_57120_57623.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_57624_58115.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_58116_59111.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_59112_61079.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_61080_67319.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_67320_67571.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_67572_67835.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_67836_68063.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_68064_68111.png rc3-mcr-11366-eng-deu-Ramming_Enclave_Gates_A_Systematic_Vulnerability_Assessment_of_TEE_Shielding_R_68112_68330.png
So, for the next talk, I have Jo van Bulk and Fritz Alder from the University of Löwen in Belgium and David Oswald, a professor for cybersecurity in Birmingham. They are here to talk about the trusted execution environment you probably know from Intel and so on. And you should probably not trust it all the way because it's software and it has its flaws. And so they're talking about ramming enclave gates, which is always good, a systematic vulnerability assessment of TE shielding runtimes. Please go on with the talk. Hi everyone, welcome to our talk. So I'm Jo from the E-Mate Disonet Research Group at Kea Löwen. And today joining me are Fritz also from Löwen and David from the University of Birmingham. And we have this very exciting topic to talk about ramming enclave gates. But before we dive into that, I think most of you will not know what are enclaves, let alone what are these TEs. So let me first start with some analogy. So enclaves are essentially sort of a secure fortress in the processor in the CPU. And so it's an encrypted memory region that is exclusively accessible from the inside. And what we know from the last history of fortress attacks and defenses, of course, is that when you cannot take a fortress because the walls are high and strong, you typically aim for the gates, right? That's the weakest point in any fortress defense. And that's exactly the idea of this research. So it turns out to apply to enclaves as well. And we have been ramming the enclave gate. We have been attacking the input-output interface of the enclave. So a very simple idea, but very drastic consequences, I dare to say. So this is sort of the summary of our research with over 40 interface sanitization vulnerabilities that we found in over eight widely used open source enclave projects. So we will go a bit into detail over that in the rest of the slides. Also, a nice thing to say here is that this resulted in two academic papers to date, over seven CVEs, and altogether quite some responsible disclosure lengthy and viral periods. OK, so I guess we should talk about why we need such enclave fortresses anyway. So if you look at traditional kind of like operating system or computer architecture, you have a very large trusted computing base. So for instance, on the laptops that you most likely use to watch this talk, you trust the kernel, you trust maybe a hypervisor if you have, and the whole hardware under the system, so CPU, memory, maybe hard drive, trusted platform module, and the likes. So actually the problem is here with such a large TCB, trusted computing base, you can also have vulnerabilities basically everywhere, and also malware hiding in all these parts. So the idea of this enclave execution is, as we find for instance in Intel SGX, which is built into most recent Intel processors, is that you take most of the software stack between an actual application, here the enclave app, and the actual CPU out of the TCB. So now you only trust really the CPU, and of course you trust your own code, but you don't have to trust the OS anymore, and SGX for instance promises to protect against an attacker who has achieved a route in the operating system, and even depending on who you ask against, for instance a malicious cloud provider, so imagine you run your application on the cloud, and then you can still run your code in a trusted way, with hardware level isolation, and you have attestation and so on, and you no longer really have to trust even the administrator. So the problem is of course that attack surface remains, so previous attacks and some of them I think will also be presented at this remote congress this year, have targeted vulnerabilities in the micro architecture of the CPU. So you are attacking basically the hardware level, so you have foreshadow, you have micro architecture data sampling, specter and LVI and the likes, but what less attention has been paid to, and what we'll talk about more in this presentation, is the software level inside the enclave, which I hinted at, that there's some software that you trust, but now we look in more detail into what actually is in such an enclave from the software side. So can an attacker exploit any classical software vulnerabilities in the enclave? Yes, David, that's quite an interesting approach, right? Let's aim for the software, so we have to understand what is the software landscape out there for these SGX enclaves and DEs in general. So that's what we did, we started with an analysis and you see some screenshots here, this is actually a growing open source ecosystem, many of these run times, library opening system SDKs. And before we dive into the details, I want to stand still with what is the common factor that all of them share, right? What is kind of the idea of these enclave development environments? So here, what any DE to set execution environment gives you is this notion of a secure enclave oasis in a hostile environment, right? And you can do secure computations in that green box while the outside world is burning. As with any defense mechanism, as I said earlier, the devil is in the details and typically at the gate, right? So how do you mediate between that undisturbed world where the desert is on fire and the secure oasis in the enclave? And the intuition here is that you need some sort of intermediary software layer, which what we call a shielding runtime. So it kind of makes a secure bridge to go from the interstitled to the enclave and back. And that's what we are interested in, right? To see what kind of security checks you need to do there. So it's quite a beautiful picture. You have on the right the fertile enclave, and on the left the hostile desert. And we make this secure bridge in between. And what we are interested in is what if it goes wrong? What if your bridge itself is flawed? So to answer that question, we look at that yellow box and we ask what kind of sanitizations, what kind of security checks do you need to apply when you go from the outside to the inside and back from the inside to the outside? And one of the key contributions that we have built up in the past two years of this research, I think, is that the yellow box can be subdivided into two smaller subsequent layers. And the first one is this ABI application binary interface, very low level CPU state. And the second one is what we call API application programming interface. So that's the kind of state that's already visible at the programming language. Then the remainder of this presentation, we will kind of guide you through some relevant vulnerabilities at both these layers to give you an understanding of what this means. So first Fritz will guide you to the exciting low level landscape of the ABI. Yeah, exactly. And you just said it's the CPU state, and it's the application binary interface. But let's take a look at what this means, actually. So it means basically that the attacker controls the CPU register contents. And we do have to proceed. And that on every enclave entry or on every enclave exit, we need to perform some tasks so that the enclave and the trust runtime have some well initialized CPU state. And the compiler can work with the calling conventions that it expects. So these are basically the key part. We need to initialize the CPU registers when entering the enclave and scrubbing them when we exit the enclave. So we can't just assume anything that the attacker gives us as a given. We have to initialize it to something proper. And we looked at multiple TTE runtimes and then multiple TEs. And we found a lot of vulnerabilities in this ABI layer. And one key insight of this analysis is basically that a lot of these vulnerabilities happen on complex instruction set processors. So on CISC processors. And basically on the InternetGX TTE. We also looked at some RISC processors. And of course, it's not representative. But it's immediately visible that a complex x86 ABI seems to have a way higher, larger tech surface than the simpler RISC designs. So let's take a look at one example of this more complex design. So for example, there's the x86 string instructions that are controlled by the direction flag. So there's a special x86 rep instruction that basically allows you to perform stream memory operations. So if you do like a memset on a buffer, this will be compiled into the rep string operation instruction. And the idea here is basically that the buffer is read from left to right and well, written over by memset. But this direction flag also allows you to go through it from right to left, so backwards. Let's not think about why this was a good idea or why this is needed. But definitely it is possible to just set the direction flag to one and run this buffer backwards. And what we found out is that the system VABI actually says that this must be clear or set to forward on function entry and return. And that compilers expect this to happen. So let's take a look at this when we do this in our enclave. So in our enclave, when we in our trusted application perform this memset on our buffer, on normal entry with the normal direction flag, this just means that we walk this buffer from front to back. So you can see here, it just runs correctly from front to back. But now if the attacker enters the enclave with the direct direction flag set to one, so it sets to run backwards, this now means that from the start of our buffer, so from where the pointer points right now, you can now see it actually runs backwards. So that's the problem. And that's definitely something that we don't want in our trust applications. Because, well, as you can think, it allows you to override keys that are in the memory locations that you can go backwards. It allows you to read out things. That's definitely not something that is useful. And when we reported this, this actually got a nice CD assigned with the base core high, as you can see here in the next slide. And, well, you may think, OK, well, that's one instance. And you just have to think of all the flex to sanitize and all the flex to check. But wait, of course, there's always more. So as we found out, there's actually the floating point units, which comes with a whole lot of other registers and a whole lot of other things to exploit. And I will spare you all the details. But just for this presentation, just know that there is an older x87FPU and new SSE that does vector float. This is vector floating point operations. So there's the FPU control word and the MXCSR register for these newer instructions. And this x87FPU is older, but it's still used, for example, for extended precision, like long double variables. So old and new doesn't really apply here because both are still relevant. And that's kind of the thing with x86 and x87 here, that old archaic things that you could say are outdated are still relevant or are still used nowadays. And again, if you look at the system VABI now, we saw that these control bits are coalescated. So they are preserved across function codes. And the idea here is, which to some degree holds merit, is that these are some global states that you can set. And they are transferred within one application. So one application can set some global state and keeps the state across all its usage. But the problem here, as you can see here, then is our application or Enclave is basically one application. And we don't want our attacker to have control over the global state within our trusted application. So what happens if PUS settings are preserved across codes? Well, for a normal user, let's say we just do some calculation inside the Enclave, like 2.1 times 3.4, which just nicely calculates to a 7.14 long double. That's nice. But what happens if the attacker now enters the Enclave with some corrupt precision and rounding modes for the FPU? Well, then we actually get another result. So we get distorted results with the lower precision and different rounding modes. So it's actually rounding down here, whenever it exceeds the precision. And this is something we don't want. So this is something where the developer expects certain precision or a long double precision, but the attacker could actually just reduce it to a very short precision. And we reported this, and we actually found this issue also in Microsoft Open Enclave. That's why it's marked as not exploitable here. But what we found interesting is that the Intel SGX SDK, which was vulnerable, patched this with an X restore instruction, which completely restores the extended state to a known value. While Open Enclave only restores the specific register that was affected, the load MXC SR instruction. And so let's just skip over the next few slides here, because I just want to give you the idea that this was not enough. So we found out that even if you restore this specific register, there's still another data register that you can just mark as in use before entering the Enclave, and with which the attacker can make that any floating point calculation results in another number. And this is silent, so this is not programming language specific, this is not developer specific. This is a silent ABI issue that the calculations are just not a number. So we also reported this. And now, thankfully, all Enclave runtime uses full X restore instruction to fully restore this extended state. So it took two CDs, but now luckily, they all perform this nice full restore. So I don't want to go into the full details of our use cases now or of our case studies that we did now. So let me just give you the ideas of these case studies. So we looked at these issues and wanted to look into whether they just feel difficult or whether they are a bet. And we found that we can use overflows as a side channel to deduce secrets. So for example, the attacker could use this register to unmask exceptions that inside the Enclave are then triggered by some input dependent multiplication. And we found out that these side channels, if you have some input dependent multiplication, can actually be used in the Enclave to perform a binary search on this input space. And we can actually retrieve this multiplication secret with a deterministic number of steps. So even though we adjust it like a single mask, we flip, we can actually retrieve the secret with deterministic steps. And just so that you know there's more you can do, we can also do machine learning in the Enclave. So if you all said it nicely, you can run it inside the TE, inside the cloud. And that's great for machine learning, right? So let's do hand written digit recognition. And if you look at just the model that we look at, we just have two users where one user pushes some machine learning model and the other user pushes some input. And everything is protected with Enclave, right? So everything is secure. But we actually found out that we can poison these FPU registers and degrade the performance of this machine learning down from all digits were predicted correctly to just 8% of digits were correctly. And actually, all digits were just predicted the same number. And this basically made this machine learning model useless. There's more we did. So we can also attack Blender with image differences, slight differences between Blender images. But that's just for you to see that it's small. But it's a tricky thing and intricate that can go wrong very fast on the ABI level once you play around with it. So this is about the CPU state. And now we will talk more about the application programming interface that I think more of you will be comfortable with. Yeah, we take, thank you Fritz. We take quite a simple example. So let's assume that we actually load the standard Unix binary into such an Enclave. And there are frameworks that can do that, such as a Graphina. So and what I want to illustrate with that example is that it's actually very important to check where a point has come from. Because the Enclave kind of partitions the memory into untrusted memory and Enclave memory. And they live in a shared address space. So the problem here is as follows. Let's assume we have an echo binary that just prints an input. And we give it as an argument string. And that normally, when everything is fine now, points to some string, let's say, hello world, which is located in the untrusted memory. So if everything runs as it should, this Enclave will run, will get the pointer to untrusted memory, and will just print that string. But the problem is now actually the Enclave has access also to its own trusted memory. So if you don't check this pointer and the attacker passes a pointer to the secret that might live in Enclave memory, what will happen? Well, the Enclave will fetch it from there and will just print it. So suddenly you have turned this kind of like into a memory disclosure vulnerability. And we can see that in action here for the framework named Graphine that I mentioned. So we have a very simple hello world binary. And we run it with a couple of command line arguments. And now in on the untrusted side, we actually change a memory address to point into Enclave memory. And as you can see, normally it should print here test. But actually it prints a super secret Enclave string that lift inside the memory space of the Enclave. So these kind of vulnerabilities are quite well known from user to kernel research and from other instances. And they're called confused deputies. So the deputies kind of like has a gun, can read the Enclave memory and suddenly then does something which is not supposed to do because it didn't really check where the memory should belong or not. So I think this vulnerability seems to be quite trivial to solve. You simply check all the time where pointers come from. But as you will tell, it's often not quite that easy. Yes, David, that's quite insightful. We should check all of the pointers. So that's what we did. We checked all of the pointer checks. And we noticed that Intel has a very interesting kind of algorithm to check these things. Of course, the Intel code is high quality. They checked all of the pointers. But you have to do something special for strings. And we're talking here the C programming language. So strings are null terminated. They end with a null byte. And you can use the function sdln string length to compute the length of the string. And let's see how they check whether your string lights completely outside of Enclave memory. So the first step is you compute the length of the interested string. And then you check whether the string from start to end lights completely outside of the Enclave. That sounds legit, right? And you reject the string. So this works beautifully. Let's see however how it behaves when we pass on a legal string. So we are not going to pass the string hello world outside of the Enclave. But we pass some string secret one that lies within the Enclave. So the first step will be that the Enclave starts computing the length of that string that lies within the Enclave. And that sounds already fishy. But then luckily everything comes OK, because then it will detect that this actually should never have been done and that the string lies inside the Enclave. So it will reject the e-cals, or the call into the Enclave. So that's fine. But some of you who know side channels know that this is exciting, right? Because the Enclave did some computation it was never supposed to do. And the length of that computation depends on the amount of non-zero bytes within the Enclave. So what we have here is a side channel where the Enclave will always return false. But the time it takes to return false depends on the amount of zero bytes inside that secret Enclave memory blob. So that's what we found. We were excited. And we said, OK, that's a simple timing channel. Let's go to that. So we did that. And you can see a graph here. And it turns out it's not as easy as it seems, right? So I can tell you that the blue one is for a string of length one and the red one is for a string of length two. But there is no way you can see that from that graph. Because x86 processors are lightning fast so that one single increment instruction is completely dissolves into the pipeline. You will not see that by measuring execution time. So we need something different. And while we are smart, so we read papers. And in literature, one of the very common attacks in SJX is also something that Intel describes here. You can see which memory pages 4K memory blocks are being accessed while the Enclave executes because you control the operating system and the paging machinery in there. So that's what we tried to do. And we thought this is a nice side channel. And we were there sketching our head looking at that code, a very simple for loop that fits entirely within one page and a very short string that fits entirely within one page. So just having access to 4K memory regions is not going to help us here, right? Because vote the code and the data fit on a single page. So this is essentially what we call the temporal resolution of the side channel. This is not accurate enough. So we need another trick. And well, here we have been working on quite an exciting framework. It uses interrupts. And it's called SGX Step. So it's a completely open source framework on Hitup. And what it allows you to do essentially is to execute an Enclave one step at a time. Hence the name. So it allows you to interleave the execution of the Enclave with attacker code after every single instruction. And the way we pulled it off is highly technical. We have this Linux kernel driver and a little library operating system running in user space. But that's a bit out of scope. The matter is that we can interrupt an Enclave after every single instruction. And then let's see what we can do with that. So what we essentially can do here is to execute that for loop with all these x86 increment instructions one at a time. And after every interrupt, we can simply check whether the Enclave accessed the string residing at our target as memory location. Another way to think about it is that we have that execution of the Enclave. And we can break that up into individual steps and then just count the steps. And hence, have a deterministic, eigen-alive timing channel. So in other words, we have an Oracle that tells you where all zero bytes are in the Enclave. I don't know if that's useful, actually, Dave. So it turns out it is. I mean, some people who might be into exploitation already know that it's good to know whether zero is somewhere in memory or not. And we now do one example. We break AES and I, which is the hardware acceleration of Intel process for AI. So finally, that actually operates only on registers. And Joe just said he can do that on pointers, on memory. There's another trick that comes into play here. So whenever the Enclave is interrupted, it will store its current registers state somewhere to memory called the SSA frame. So we can actually interrupt the Enclave, make it write its register to SSA memory, and then we can run the zero byte Oracle on the SSA memory. And what we figure out is where zero is, or if there's any zero in the AES state. So I don't want to go into the gory details of AES. But what we basically do is we find whenever there's zero in the last in the state before the last round of AES, and then that zero will go down through the S-box, will be x or to a key byte, and then that will give us a ciphertext. But we actually know the ciphertext byte. So we can go backwards. We can compute from the zero up to here and from here to this x or. And that way, we can compute directly one key byte. So we repeat that whole thing 16 times until we have found zero in every byte of this state before the last round. And that way, we get the whole final round key. And for those that know AES, if you have one round key, you have the whole key in it. So you get like the original key. You can go backwards. So sounds complicated, but it's actually a very fast attack when you see it running. So here is SGX step doing this attack. And as you can see within a couple of seconds, and maybe 520 invocations of AES here, we get the full key. So that's actually quite impressive, especially because one of the points in AES and I is that you don't put anything in memory, but there's this interaction with SGX, which is kind of like allows you to put stuff into memory. So I want to wrap up here. We have found various other attacks. So both in research code and in production codes, such as the Intel SDK and the Microsoft SDK, and they basically go across the whole range of vulnerabilities that we have often seen already from user to kernel research. But there are also some interesting new kind of vulnerabilities due to some of the aspects we explained. There was also a problem with O-calls, that is when the enclave calls into untrusted codes, so that is used when you want to, for instance, emulate system calls and so on. And if you return some kind of like a wrong result here, you could again go out of bounds. And they were actually quite widespread. And then finally, we also found some issues with padding, with leakage in the padding. I don't want to go into details. I think we have learned a lesson here that we also know from the real world. And that is important to wash your hands. So it's also important to sanitize, enclave state, to check pointers and so on. So that is kind of one of the takeaway messages, really, is that to build enclave securely, yes, you need to fix all the hardware issues, but you also need to write safe code. And for enclaves, that means you have to do proper ABI and API sanitizations. And that's quite a difficult task, actually, as we've seen, I think, in that presentation. There's quite a large attack surface due to the attack model, especially of Intel SGX, where you can interrupt after every instruction and so on. And I think from a research perspective, there's really a need for a more principled approach than just bug hunting. If you want, maybe we can learn something from the user-to-carnal analogy, which I invoked, I think, a couple of times. So we can learn kind of like what an enclave should do from what we know about what a kernel should do. But there are quite important differences also that need to be taken account. So I think, as you said, all our code is open source, so you can find that on the below GitHub links. And you can, of course, ask also questions after you have watched this talk. So thank you very much. Hello. So back again, here are the questions. Hello to see you live. We have no questions yet, so you can put up questions in the IRC below if you have questions. And on the other hand, oh, let me close this up. So I'll ask you some questions. How did you come about this topic and how did you meet? Well, that's actually interesting. I think this research has been building up over the years. And there is some. So I think some of the vulnerabilities from our initial paper, I actually already started in my master thesis to sort of see and collect. And we didn't really see the big picture until I think I met David and his colleagues from Birmingham at an event in London, the RISE conference. And then we started to collaborate on this and to look at this a bit more systematic. So I started with this whole list of vulnerabilities. And then with David, we kind of made it into a more systematic analysis. And that was sort of a Pandora's box, I dare to say. From that moment on, these kind of same errors keeping repeated. And then also Fritz, who recently joined our team in Leuven, started working together with us on more of this low level CPU state. And that's Pandora's box in itself, I would say, especially one of the lessons, as we say there, that x86 is extremely complex. And turns out that almost all of that complexity, I would say, can be abused potentially by adversaries. So it's more like a fractal in a fractal in a fractal. You're opening a box and you're getting more and more of questions out of that. In a way, I think, yes, I think it's fair to say this research is not the final answer to this. But it's rather an attempt to give a systematic way of looking at a poorly never ending attacker defender race. So there is a question from the internet. So are there any other circumstances where AES minus NE is writing its registers into memory, or is this exclusive to SGX? Should I repeat? I do not understand the question either. So I think the question is that this AES attack that David presented depends on, of course, having a memory disclosure attack to read the register content. And we pull that off using SGX step to forcibly write the register content into memory. So that is definitely SGX specific. However, I would say one of the lessons from, let's say, the past five years of SGX research is that often these things generalize beyond SGX. And at least the general concept of, let's say, the insight that CPU registers end up in memory one way or another sooner or later. I think that also applies to operating systems. If you somehow can force an operating system to context it between two applications, it will also have to dump the register content temporarily in memory. So if you would have something similar like what we have in an operating system kernel, you would potentially mount a similar attack. But maybe David wants to say something about operating systems there as well. No, not really. I think one thing that helps with SGX is that you have very precise control, as you explained with the interrupts and stuff, because you root outside the enclave. So you can single step, essentially, the whole enclave whereas interrupting the operating system at exactly repeatedly, at exactly the point you want or some other process or so tends to be probably harder just by design. But of course, on a context switch, CPU has to save somewhere its register set, and then it will end up in memory in some situations, probably not as controlled as it is for SGX. So there is the question, what about other CPU architectures other than Intel? Did you test those? So maybe I can go into this. So well, interest SGX is the, let's say, largest one with the largest software base and the most enclave shooting runtimes that is also that we could look at. But there are, of course, some others. So for example, we have this internal TE that we developed at SanQus. Some years ago, it's called SanQus. And of course, for these, there are similar issues. So you always need the software layer to interact, to enter the enclave and to access the enclave. And I think you and David in the earlier work also found issues in our TE. So it's not just Intel and related projects that mess up, there, of course. But what we definitely found is that it's easier to think of all edge cases for simpler designs like RISC-5 or simpler RISC designs than for this complex X86 architecture. So right now, there are not that many besides Intel SGX. So they have the advantage and disadvantage of being the first widely deployed, let's say. But I think as soon as others start to grow out and simpler designs start to be more common, I think we will see this that it's easier to fix all edge cases for simpler designs. OK, so what is a reasonable alternative to TE? Or is there any? You do you want to take that or should I say what? Well, we can probably both give our perspective. So I think, well, the question to start with, of course, is do we need an alternative? Or do we need to find more systematic ways to sanitize the software layers? That's, I think, one part of the answer here, that we don't have to necessarily throw away TEs because we have problems with them. We can also look at how to solve those problems. But apart from that, there is some exciting research that maybe David also wants to say a bit more about, for instance, on capabilities. That's in a way not so different than TE is necessary. But when you have hardware support for capabilities, like the Cherry Project in Cambridge, which essentially associates metadata to a pointer, metadata like permission checks, then you could, at least for a subclass of the issues we talked about, pointer poisoning attacks, you could natively leakage those with hardware support. But it's a very high level idea. Maybe David wants to say something. Yeah, so I think like an alternative to TE is, whenever you want to partition your system into parts, which is, I think, a good idea. And everybody is now doing that also in there, how we build online services and stuff. So TEs are one system that we have become quite used to from mobile phones or from maybe even from something like a banking card or so, which is also like a protected environment for a very simple job. But the problem then starts when you throw a lot of functionality into the TE. As we saw the trusted code base becomes more and more complex and you get traditional bugs. So think like, yeah, it's really the question if you need an alternative or a better way of approaching it, how your partition software. And as you mentioned, there are some other things you can do architecturally so you can change the way we or extend the way we build architectures, for instance, with this capabilities and then start to isolate components, for instance, in one software project, say in your web server, you isolate the TLS stack or something like this. And also thanks for the people noticing the secret password here. So obviously only for decoration purposes to give the people something to watch. So but it's not fundamentally broken, is it? SGX. Yeah, no, SGX TE. I mean, TE's are the menu of them. I think like you cannot say fundamentally broken for it. But for SGX it has. The question I had was specifically for SGX at that point, because Signal uses it, mobile coin, cryptocurrency uses it and so on and so forth. Is that fundamentally broken or would you rather say? So I guess it depends what you call fundamentally. So there has been in the past we have worked also on what I would say full breaches of SGX. But they have been fixed. And it's actually quite a beautiful instance of where research can have short term industry impact. So you find a vulnerability, then the vendor has to devise a fix that they are often not reveal. And they often work around to the problem. And then later, because we are talking of course about hardware roots of trust, so then you need no processes to really get a fundamental fix for the problem. And then you have temporary work arounds. So I would say, for instance, a company like Signal using SGX, if they. So it does not give you security by default. You need to think about the software. That's what you focused on in this talk. You also need to think about all of the hardware microcode patches and or new processors to take care of all the known vulnerabilities. And of course the question always remains, are there vulnerabilities that we don't know yet? That's with any secure system, I guess. But maybe also David wants to say something about some of his latest work there. That's a bit interesting. Yeah, so I think what you said, or my answer to this question would be, it depends on your threat model, really. So some people use SGX as a way to kind of like remove the trust in the cloud providers. So you say like as in Signal or so, I move all this functionality that is hosted maybe on some cloud provider into an SGX enclave. And then I don't have to trust the cloud provider anymore because SGX also has some form of protection against physical access. But recently we actually, we published another attack which shows that if you have hardware access to an SGX processor, you can inject faults into the processor by playing with the undervolting interface with hardware access. So you really solder to the main board to a couple of wires on the bus to the voltage regulator. And then you can do voltage glitching as some people might know from other embedded contexts. And that way then you can flip bits essentially in the enclave and of course do all kinds of, kind of like inject all kinds of evil effects that then can be used further to get keys out or maybe hijack control flow or something. So it depends on your threat model. I wouldn't say still that SGX is completely pointless. It's, I think better than not having it at all, but it definitely cannot, you cannot have like complete protection against somebody who has physical access to your server. So I have to close this talk. It's a bummer. I would ask all that questions that are flowing here. But one very, very fast answer please. What is that with a password in your background? I explained it. It's of course like just a joke. So I'll say it again because some people seem to have taken it seriously. So it was such an empty whiteboard. So I put a password there. Unfortunately, it's not fully visible in the, in the stream. Okay. So I thank you, Jo van Boek, Fritz Alder, David Oswald. Thank you for having that nice talk. And now we make the transition to the Herod New Show. Thank you.
talk about the trusted execution environment you assessment of TE shielding runtimes. Please go on turns out to apply to enclaves as well. And we the summary of our research with over 40 interface sanitization vulnerabilities that we enclave projects. So we will go a bit into detail altogether quite some responsible disclosure is in such an enclave from the software side. So vulnerabilities in the enclave? Yes, David, and we ask what kind of sanitizations, what kind two years of this research, I think, is that the some relevant vulnerabilities at both these exciting low level landscape of the ABI. Yeah, the CPU register contents. And we do have to some well initialized CPU state. And the compiler can work with the calling conventions that it of these vulnerabilities happen on complex instruction set processors. So on CISC example, there's the x86 string instructions that and the MXCSR register for these newer is that the Intel SGX SDK, which was vulnerable, completely restores the extended state to a known value. While Open Enclave only restores the developer specific. This is a silent ABI issue that the calculations are just not a number. So Enclave runtime uses full X restore instruction actually found out that we can poison these FPU predicted correctly to just 8% of digits were predicted the same number. And this basically about the CPU state. And now we will talk more about the application programming interface that I think more of you will be comfortable with. Enclave. And there are frameworks that can do Enclave memory. And they live in a shared address line arguments. And now in on the untrusted side, we actually change a memory address to point into memory space of the Enclave. So these kind of string from start to end lights completely example. We break AES and I, which is the finally, that actually operates only on AES, and then that zero will go down through the research code and in production codes, such as basically go across the whole range of that means you have to do proper ABI and API surface due to the attack model, especially of kind of made it into a more systematic analysis. to give a systematic way of looking at a poorly at. But there are, of course, some others. So for advantage and disadvantage of being the first start to be more common, I think we will see this of the issues we talked about, pointer poisoning industry impact. So you find a vulnerability, they. So it does not give you security by patches and or new processors to take care of all that nice talk. And now we make the transition to