We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Ramming Enclave Gates: A Systematic Vulnerability Assessment of TEE Shielding Runtimes

00:00

Formal Metadata

Title
Ramming Enclave Gates: A Systematic Vulnerability Assessment of TEE Shielding Runtimes
Title of Series
Number of Parts
275
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
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.
Keywords
Chi-squared distributionSoftware testingChaos (cosmogony)Universe (mathematics)Goodness of fitRun time (program lifecycle phase)Vulnerability (computing)SoftwareQuicksortAnalogyLogic gateAdditionIntelForcing (mathematics)Computer animationXMLMeeting/Interview
Information securityIdeal (ethics)Interface (computing)outputFunction (mathematics)Multitier architecturePointer (computer programming)IntegerBuffer overflowInterface (computing)String (computer science)FlagEmbargoFrequencySurfaceKernel (computing)BefehlsprozessorHard disk driveComputer hardwareIntelMikroarchitekturEncryptionBefehlsprozessorProcess (computing)Semiconductor memoryLogic gateInterface (computing)Classical physicsPresentation of a groupComputer architectureRoutingModule (mathematics)Point (geometry)Computer hardwareCartesian coordinate systemStack (abstract data type)Vulnerability (computing)Thermodynamisches SystemCloud computingOperating systemQuicksortComputing platformLaptopNeuroinformatikLevel (video gaming)Slide ruleBitProjective planeFrequencySoftwareFunction (mathematics)outputSurfaceOpen sourceCodeInstance (computer science)Decision theoryHard disk driveMereologyAngleHand fanSystem administratorWorkstation <Musikinstrument>Point cloudEmbargoOperational amplifierMobile appGroup actionVideo gameComputer animation
IntelSoftwareTime zoneoutputInternet der DingeOpen sourceOpen setSoftware development kitThermodynamisches SystemBasis <Mathematik>CompilerBridging (networking)Run time (program lifecycle phase)SoftwareMereologyQuicksortLogic gateUltraviolet photoelectron spectroscopyMechanism designResultantGoodness of fitMultiplication signOpen sourceSoftware developerInformation securityThermodynamisches SystemCuboidNeuroinformatikGreatest common divisorSet (mathematics)Mathematical analysisLibrary (computing)Bridging (networking)Run time (program lifecycle phase)Computer animation
Binary codeRun time (program lifecycle phase)Computer programmingInterface (computing)Multitier architectureBefehlsprozessorStack (abstract data type)CompilerMathematical analysisFloating-point unitPointer (computer programming)SurfaceFlagIntelPC CardKolmogorov complexityString (computer science)Tape driveRead-only memoryOperations researchMilitary operationSoftwareFunction (mathematics)Standard deviationSystem callSoftware development kitPrime idealoutputOvalSummierbarkeitAlgebraic closureInformation securityRight angleBridging (networking)CuboidCartesian coordinate systemQuantum stateVulnerability (computing)Run time (program lifecycle phase)BefehlsprozessorInterface (computing)SpeicheradresseBinary codePoint (geometry)Direction (geometry)Buffer solutionFlagNormal (geometry)CompilerThermodynamisches SystemFunktionalanalysisOperator (mathematics)Level (video gaming)Reduced instruction set computingComputer programmingComplex instruction set computingRepetitionStreaming mediaString (computer science)Semiconductor memoryComplex analysisMultiplicationKey (cryptography)Core dumpSlide ruleInstance (computer science)MereologyContent (media)Electronic program guideSeries (mathematics)Proper mapFerry CorstenSurfaceMathematical analysisPointer (computer programming)CompilerData structureTouchscreenOptical disc driveObject (grammar)Forcing (mathematics)Sampling (statistics)Dependent and independent variablesElectronic mailing listWaveAxiom of choiceMultiplication signGame controllerTask (computing)Self-organizationBoss CorporationBit rateLengthWordVotingRoundness (object)Group actionOrbitSound effectRoutingComputer animation
Extension (kinesiology)Point (geometry)Floating-point unitControl flowWordExecution unitOperations researchThermodynamisches SystemSystem callAsynchronous Transfer ModeIntelSoftware development kitoutputBuffer overflowCountingBinary codeSoftware testingData modelPredictionNumerical digitSingle-precision floating-point formatExecution unitPoint (geometry)DigitizingoutputOperator (mathematics)Buffer overflowNumberFormal languageCalculationCASE <Informatik>Side channel attackObservational studyException handlingMultiplicationAddress spaceMachine learningRun time (program lifecycle phase)Auditory maskingVirtual machinePattern recognitionLatent heatQuantum stateAsynchronous Transfer ModeSet (mathematics)Game controllerCartesian coordinate systemSoftware developerVector spaceSystem callDoubling the cubeVariable (mathematics)BitFunktionalanalysisDegree (graph theory)Open setEndliche ModelltheorieThermodynamisches SystemExtension (kinesiology)Multiplication signWordResultantStructural loadSlide ruleForcing (mathematics)Presentation of a groupMedical imagingDifferent (Kate Ryan album)Reading (process)Right angleShooting methodSelf-organizationForestPrisoner's dilemmaForm (programming)Data storage deviceCollisionOrder (biology)DeterminismSound effectPosition operatorDecision theoryGroup actionCombinational logicWaveRule of inferenceLevel (video gaming)Computer animation
Computer-generated imageryMultitier architectureRead-only memoryPointer (computer programming)Different (Kate Ryan album)Medical imagingLevel (video gaming)BefehlsprozessorSemiconductor memoryUniqueness quantificationString (computer science)Interface (computing)outputMessage passingPoint (geometry)Pointer (computer programming)PRINCE2Letterpress printingParameter (computer programming)Binary codeECosSoftware frameworkCartesian coordinate systemWordComputer programmingStandard deviationQuantum statePartition (number theory)Vulnerability (computing)Address spaceComputer animation
Pointer (computer programming)Beer steinString (computer science)Software development kitNP-hardIntelRead-only memoryComputerFormal verificationEntire functionOracleIdeal (ethics)BuildingSpeicheradresseTime domainInformation securityInformationCodeLatent heatWeb pageBlock (periodic table)Software developerThread (computing)ImplementationCountingTemporal logicImage resolutionSeitentabelleInterrupt <Informatik>Kernel (computing)SpeicheradresseSemiconductor memoryInstance (computer science)Address spaceString (computer science)Task (computing)Line (geometry)Software frameworkGroup actionWordParameter (computer programming)Binary codeInheritance (object-oriented programming)Side channel attackInterrupt <Informatik>NeuroinformatikThermodynamisches SystemLengthMultiplication signBlock (periodic table)Graph (mathematics)CodeBefehlsprozessorProgramming languageLibrary (computing)Single-precision floating-point formatDisk read-and-write headLoop (music)Web pageDialectOnline helpBitVulnerability (computing)Pointer (computer programming)DeterminismComputer iconKernel (computing)AlgorithmRadical (chemistry)FunktionalanalysisSystem callLie groupOpen sourceDevice driverMenu (computing)Point (geometry)Lipschitz-StetigkeitGreatest elementRight angleQuicksortOraclePhase transitionService (economics)VotingGame theoryType theoryDifferent (Kate Ryan album)PlanningOffenes KommunikationssystemImage resolutionOperating systemJSONComputer animation
OracleCiphertextOracleSemiconductor memoryWordExploit (computer security)Control flowProcess (computing)Quantum statePointer (computer programming)Ocean currentFrame problemRoundness (object)EncryptionCuboidExclusive orMultiplication signComputer hardwareKey (cryptography)CiphertextPoint (geometry)NeuroinformatikCausalityComputer animation
Conditional-access moduleOracleComputer programmingCodeSurfaceMultitier architectureIntegerBuffer overflowPointer (computer programming)String (computer science)Library (computing)Exclusive orInterface (computing)Thermodynamisches SystemSystem callArmPoint (geometry)Semiconductor memory2 (number)Office suiteVulnerability (computing)Range (statistics)CodeInstance (computer science)ResultantBound stateKernel (computing)System callUniversal product codeProduct (business)RoutingCausalityThermodynamisches SystemComputer animation
Message passingSurfaceKernel (computing)AnalogyPointer (computer programming)Quantum stateNP-hardMessage passingComputer hardwareKernel (computing)Endliche ModelltheorieProper mapAnalogyMultiplication signDifferent (Kate Ryan album)Link (knot theory)WritingOpen sourceCodePresentation of a groupIntelPerspective (visual)Software bugSurfaceWeightTask (computing)Set (mathematics)Computer animation
Point (geometry)Computer hardwareSoftwareVulnerability (computing)Run time (program lifecycle phase)Computer architectureRight angleCASE <Informatik>Exterior algebraPerspective (visual)MereologyBitInstance (computer science)Projective planeAssociative propertyOperating systemMikroarchitekturMetadataSoftware testingSemiconductor memoryInterrupt <Informatik>HypothesisElectronic mailing listQuicksortAvatar (2009 film)CuboidLevel (video gaming)Moment (mathematics)Error messageInternetworkingContent (media)Thermodynamisches SystemContext awarenessPointer (computer programming)BefehlsprozessorIntelCartesian coordinate systemComplex analysisSimilarity (geometry)Kernel (computing)Quantum stateRoutingProcess (computing)Shooting methodTotal S.A.ForestDirected graphMonster groupIdentity managementGoodness of fitForcing (mathematics)PhysicalismGame controllerMusical ensembleWritingAutomatic differentiationDivisorDirection (geometry)Meeting/Interview
Online service providerThermodynamisches SystemSoftwareExterior algebraBuildingComputer architectureInstance (computer science)MereologyConnectivity (graph theory)Goodness of fitProjective planePlastikkarteWeb 2.0Process (computing)Server (computing)FunktionalanalysisCuboidCodeExtension (kinesiology)Meeting/Interview
WhiteboardMotherboardEndliche ModelltheorieComputer hardwareVulnerability (computing)Right angleRootProcess (computing)BitSound effectMobile WebComplete metric spaceServer (computing)PasswordStreaming mediaGroup actionCloud computingDefault (computer science)SoftwareCodePoint (geometry)Instance (computer science)Source codeFunktionalanalysisForm (programming)PhysicalismBefehlsprozessorTerm (mathematics)Bus (computing)Context awarenessInformation securityInterface (computing)ExistenceAnalogyWordInheritance (object-oriented programming)Point cloudTouch typingCoefficient of determinationKey (cryptography)Revision controlOctahedronShape (magazine)Order (biology)Computer animationMeeting/Interview
Finite element methodRule of inferenceComputer animation
Transcript: English(auto-generated)
So, for the next talk, I have Jofann Buch and Fritz Alder from the University of Leuven in Belgium, and David Oswald, a professor for cybersecurity in Birmingham. They're
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 Jof from Emektissenet Research Group at KLEuven. And today joining me are Fritz, also from Leuven, 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 TEEs. So let me first start with some analogy. So enclaves are essentially a sort of a
secure fortress in the in the process in the CPU. And so it's an encrypted memory region that is exclusively accessible from the inside. And what we know from 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 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. Okay, 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 you, 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. Now, 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 processes, is that you take most of the software stack between an actual application, here's 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, cloud providers. Imagine you run your application on the cloud, and
then you can still run your code in a trusted way with a hardware level isolation and you have attestation and so on. You don't 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're attacking basically the hardware level. So you had foreshadow, you had a micro architectural 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'll 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? And let's aim for the software. So we have to
understand what is the software landscape out there for these SGX enclaves and TEs 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, many of these runtimes, 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 TE to set execution environment gives you is this notion of a secure enclave oasis in a hostile environment.
And you can do secure computations in the 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 untrusted 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 is what we call a shielding runtime. So it kind of makes a secure bridge to go from the untrusted world 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 that 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 on 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 that on every enclave entry and on every exit, we need to perform some tasks so that the
enclave and the trusted 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 parts. 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 multiple TEEs 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 Intel GTX TEE. We also looked at some RISC processors and, of course, it's not representative, but it's immediately visible that the complex x86 ABI seems to have a way
larger tech surface than the simpler RISC designs. Let's take a look at one example of this more complex design. For example, there's the x86 string instructions that are controlled by the
direction flag. There's a special x86 rep instruction that basically allows you to perform stream memory operations. If you do a memset on a multiple PEB compiled into the rep string operation instruction. And the idea here is
basically that the buffer is read from left to right and 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. What we found out is that the system via ABI actually says that this must be clear or set to forward on function entry and return, and that compilers
expect this to happen. Let's take a look at this when we do this in our enclave. 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. You can see here it just runs correctly from front to back. But now if the attacker enters the enclave with the direction flag set to one, so that from the start of our buffer, so from
where the pointer points right now, you can now see it actually runs backwards. That's a problem, and that's definitely something that we don't want in our trusted applications because, well, as you can think, it allows you to overwrite keys that are in the memory location
that you can go backwards. It allows you to read out things. That's definitely not something that is useful. While we reported this, this actually got an ICD assigned with the base core high, as you can see here in the next slide. You may think, okay, well,
that's one instance and you just have to think of all the flags to sanitize and all the flags to check. But wait, of course, there's always more, right? As we found out,
there's actually the floating point unit, which comes with a whole lot of other registers and a whole lot of other things to exploit. I will spare you all the details, but just for this presentation, just know that there is an
X87 FPU and a new SSE that does vector floating point operations. So, there's the FPU control word and the MXCSR register for these newer instructions. This X87 FPU 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 the thing with X86 and X87 here, that old archaic things that you could say are outdated are still relevant, are still used
nowadays. And again, if you look at the System B ABI now, we saw that these control bits are quality-safe, so they are preserved across function calls. The idea here, which to some degree holds merit, is that these are some global states that you can set, and they are, well, transferred
within one application. So, one application can set some global state and keep 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, right? So, what happens if the FPU settings are preserved across calls? 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, right? But what happens if the attacker now enters the enclave with some corrupt precision and rounding mode for the FPU? Well, then we actually get another result. So, we get distorted results with the lower
precision and a different rounding mode. So, it's actually rounding down here whenever it exceeds the precision. And this is something we don't want, right? So, this is something where the developer expects a 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 restored the specific register that was affected, the load MXC as our 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 runtimes use this full X restore instruction to fully restore this extended state. So, it took two CVEs, 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 bad. 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 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 a secret with deterministic steps. And just so that you know there's more you can do, we can also do machine learning in the TEE. You can run it inside the
TEE, inside the cloud, and that's great for machine learning. So, let's do a handwritten digit recognition. 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 Enclaves. 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 treated 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 can also attack Blender with image differences, slight image
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 want 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 a standard Unix binary into such an Enclave and there are frameworks that can do that, such as Graphene or so. And what I
want to illustrate with that example is that it's actually very important to check where pointers 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 you know, an argument string and that normally, when everything is fine, 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 graphene 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 lived inside the memory space of the Enclave. So these kind of
vulnerabilities are quite well known from kernel research and from other instances and they're called confused deputy. So the deputy kind of like has a gun, can read the Enclave memory and suddenly then does something which is not supposed to do because he 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 SEO will tell you it's often not quite that easy. Yes, David, that's quite insightful, right? 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, right? 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
string length to compute the length of the string. And let's see how they check whether a string lies 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 lies completely outside of the enclave. That sounds legit, right? Then you reject the string. So this works
beautifully. Let's see, however, how it behaves when we pass an illegal string, right? So we are not going to pass this 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, right?
And that sounds already fishy, but then luckily everything comes okay 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 call, so the call into the enclave. So that's fine, but 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 of non-zero bytes within the enclave, right? 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 of zero bytes
inside of secret enclave memory block. So that that's what we found. We were excited and we said, okay, that's a simple timing channel, let's code that up. So we 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 and 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 gonna help us here right because because both the code and the data fit on a single page so so this is essentially what we call the
temporal resolution of and well here we have been working on 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 all the 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 pull it off 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 um what we essentially can do here is to execute that for loop without this x86 increment instructions one other time and after every interrupt we can simply check whether the enclave
accessed the string residing at our target that's memory location and 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 hands have a deterministic icon of 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 in into exploitation already knows that it's good to know whether zero is somewhere memory or not and we now do one example yeah we break
AESNI was which is the hardware acceleration of Intel process for AI so finally that actually operates only on registers and you just said you can kind of like 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 register state somewhere to memory called the SSA frame so we can actually interrupt the enclave make it write its memory to its register sorry to 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 this is 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 XORed to a key byte and then that will give us a cipher text but we actually know the cipher text byte and so we can go backwards so we can kind of compute we can compute from the zero up to here and from here to this XOR 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 no AES if you have one round key you have the whole key in it so you get like so original key you can go backwards
so sounds complicated but it's actually a very fast
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 also some interesting new
new kind of like vulnerabilities due to some of the aspects we explained there was also an problem with o calls that untrusted codes that is used when you want to for instance emulate system calls and so on and if you return some kind of like wrong result here
you could again go out of out of bounds and they were actually quite 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
is it's important to wash your hands here so it's also important to sanitize enclave state to check pointers and so on no so that is kind of one one of the takeaway messages really 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 sanitization and actually as as we've seen i think in 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 for from a research 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 from the user to kernel analogy which which invoked i think a couple of times
so we can learn kind of like how what an enclave should do from from what we know about what a kernel should do but they are quite important differences also that need to be taken account so i think as you said all all our code is is open source so you can find that on on the below
github links and you can of course ask also questions after 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 make 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 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 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 in and to look at this a bit more systematic so i started with this whole list of vulnerabilities and then with david we we kind of made it into a more systematic analysis and and
and and that was sort of a pandora's box i dare to say from that moment on this this kind of same errors keeping repeated and and then also who recently joined our team in leuwen started working together with us on 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 fractal in a fractal in a fractal yeah you're opening a box and you're
yes i think it's fair to say this this research is not the final answer to to this but it's rather an attempt to to to give a systematic way of looking at other probably never ending attacker defender is so
there is a question from the internet so are there any other circumstances where aes minus any is writing it's registers into memory or is this execute exclusive to sgx should i repeat i do not understand
the question either so so well i think the question is that that this aes attack that david present depends on of course having a memory disclosure attack to read the register content and and we pulled out of using sgx step to kind of forcibly write the the memory content other the register content into memory so
that is definitely specific however i would say one of the the lessons from let's say these things generalize beyond sgx and at least the general concept of let's say the insights that CPU registers end up in memory one way or another soon or later i think that also applies to
operating systems right if you somehow can force an operating system to context switch between two applications it will also have to do 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 no not really i think like one one thing that helps with sgx is that you have very precise control as as you explained with with interrupts and stuff because you were you route outside the outside the enclave so you can single step essentially the
operating system at exactly repeatedly at exactly the point you want or some other process or so tends to be probably probably harder just by design but of course on a context switch cpu has to save somewhere it's it's register set and then then it will end up in in
memory in some situations probably not not as controlled as as it is for for sgx so there is the question what other cpu architectures other than intel did you test those so maybe i can i can go into this so
well interest gx 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 right but there of course some others so for example we have our this internal t that we developed at sunk was some years ago
it's uh there's similar issues right so you always need the software layer to interact to enter the enclave interacts with the enclave and i think you and david the earlier work also found issues in our t so it's not just
intel and related related projects that mess up there of course but what we like definitely found is it's easier to to think of all edge cases for simpler designs like risk five or simpler risk designs then for this complex x86 architecture right
so right now there are not that many besides intel sjx so so they have the advantage and and disadvantage of being the first widely deployed let's say but i think as soon as others like start to to grow out and and and simple designs start to be more common i
think this that it's it's easier to fix all edge cases for simple designs okay so what is a reasonable alternative to t or is there any you do you want to take that or think should i say what
well we can probably both give our perspective so i think well the questions to start it of course is do we need an alternative or do we need to find more systematic ways to to sanitize the software layers that's i think one one part of the answer here that we don't have to necessarily throw
away these 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 but maybe david also wants to say a bit more about for instance on capabilities that that's that in a way not so different than the is necessary yeah but but when you have hardware support for capabilities like
like the cherry project in Cambridge which essentially associates metadata to a pointer metadata like permission checks then then you could at least for a subclass of the issues we talked about point point of poisoning attacks you could natively we catch those with hardware support but but it's a very high level idea maybe david
wants to say something yeah so so i think like alternative to uh t e is that's whenever you want to partition your system into into parts which is i think a good idea and everybody's now doing that also in in there how how we built online services and stuff so yeah teas are one
systems that we have become quite used to from from mobile phones or from maybe even even from something like a banking card or so which is it's also like a protected environment for a very simple job but the problem then starts when you throw a lot of functionality into the t as we saw the trusted code base becomes more
and more complex and you get traditional box so um think like yeah it's really the question if you need an alternative or a better way of approaching it how you partition software and as you mentioned there there's some other things you can do architecturally so you can change the way we or extend the way we build build architectures for instance with
these capabilities and then start to isolate components for instance in in one software project say say in your web server you isolate the TLS stack or or something like this and also thanks for the people there to to
give the people something to watch so but it's not fundamentally broken is it sjx yeah there's no sjxt i mean these are there many of them i think like you cannot say fundamentally broken for
but for sjx the question i had was specifically for sjx at that point because signal uses it mobile coin cryptocurrency uses and so on and so forth is that fundamentally broken or would you rather say so so
i guess it depends what you call fundamentally right so there has been in the past we have worked also on what i would say full breaches of sjxt but they have been fixed right and it's actually quite a beautiful instance of where research can have short term industry impact right you
find a vulnerability then the vendor has to devise a fix that they are often no trivial and and they often work around to the problem right and then the later because we are talking of course about hardware roots of this so then you need no processes to really get a fundamental fix for the problem and then you have temporary work around so
i would say for instance uh a company single using sgx if they so it does not give you security by default that you need to think about about the software that's what you focused on in this stock we also need to think about all of the the harder micro code patches and or newer closer source to to take care of all the known
vulnerabilities and and of course the question always remains are the vulnerabilities that we don't know David wants to say something about some of his latest work there that's a bit interesting yeah so I think what
what yours has or my answer to this question would be it depends on your threat model really so some some people use sgx as a way to kind of like removes the trust in the cloud providers so you you say like like as in signal or so I move all this functionality that that is hosted maybe on on some
cloud provider into an sgx enclave and then 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 into the processor by playing with the under vaulting with with hardware access so you really sort it to the main board to to a couple of couple of wires on the bus to the voltage regulator and then you can do voltage glitching as
some people might know from 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 flow or something so it depends on your
threat model i wouldn't say still that sjx 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 familiar but one very very fast answer please what is that with a password in your background i explained it's of course like just a joke so i'll say it again because some people seem to have taken it seriously so i it was such an empty white board so i put a password there unfortunately it's not fully visible in
the in the stream okay so i thank you jo fun book spritz alder david oswald thank you for this nice talk and now we make the transition to the herald news show