The ring 0 façade: awakening the processor's inner demons

Video thumbnail (Frame 0) Video thumbnail (Frame 7705) Video thumbnail (Frame 15410) Video thumbnail (Frame 16506) Video thumbnail (Frame 17452) Video thumbnail (Frame 18271) Video thumbnail (Frame 18700) Video thumbnail (Frame 23262) Video thumbnail (Frame 25599)
Video in TIB AV-Portal: The ring 0 façade: awakening the processor's inner demons

Formal Metadata

The ring 0 façade: awakening the processor's inner demons
Title of Series
CC Attribution 3.0 Unported:
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.
Release Date

Content Metadata

Subject Area
Your computer is not yours. You may have shelled out thousands of dollars for it. It may be sitting right there on your desk. You may have carved your name deep into its side with a blowtorch and chisel. But it's still not yours. Some vendors are building secret processor registers into your system's hardware, only accessible by shadowy third parties with trusted keys. We as the end users are being intentionally locked out and left in the dark, unable to access the heart of our own processors, while select organizations are granted full control of the internals of our CPUs. In this talk, we'll demonstrate our work on how to probe for and unlock these previously invisible secret registers, to break into all-powerful features buried deep within the processor core, to finally take back our own computers.
Keywords facade
Presentation of a group Building Code Numbering scheme Mereology Perspective (visual) Magnetic stripe card Programmer (hardware) Mechanism design Different (Kate Ryan album) Core dump Encryption Endliche Modelltheorie Information security Descriptive statistics Sound effect Bit Trigonometric functions 10 (number) Microprocessor Ring (mathematics) Order (biology) Right angle Quicksort Whiteboard Reading (process) Resultant Writing Reverse engineering Game controller Functional (mathematics) Existence Coprocessor Power (physics) Latent heat Bridging (networking) Computer hardware Energy level Firmware Proxy server Address space Dependent and independent variables Information Key (cryptography) Prisoner's dilemma Projective plane Wärmestrahlung Cache (computing) Uniform resource locator Word Kernel (computing) Password Pearson product-moment correlation coefficient
State observer Implementation Manufacturing execution system Service (economics) Observational study Code Password Numbering scheme Black box Coprocessor Perspective (visual) Magnetic stripe card Number Permutation Power (physics) Neuroinformatik Latent heat Different (Kate Ryan album) Core dump Energy level Endliche Modelltheorie Information security Firmware Hydraulic jump Address space Exception handling Key (cryptography) Information Content (media) Bit Arithmetic mean Word Befehlsprozessor Process (computing) Personal digital assistant Password Order (biology) Formal verification Right angle Quicksort Figurate number Table (information) Exception handling Abstraction Reading (process) Resultant Reverse engineering
Graphics tablet MUD Code Multiplication sign Password Coprocessor Leak Side channel attack Timestamp Magnetic stripe card Number Magnetic stripe card CAN bus Peer-to-peer Password Order (biology) Website Formal verification Exception handling Resultant Reading (process) Exception handling
State observer Graph (mathematics) Multiplication sign Line (geometry) Cartesian coordinate system Coprocessor Bounded variation Magnetic stripe card Number Scalable Coherent Interface
Discrete group Wechselseitige Information Group action Greatest element Service (economics) Multiplication sign Range (statistics) Side channel attack Coprocessor Magnetic stripe card Data model Latent heat Different (Kate Ryan album) Endliche Modelltheorie Exception handling Dialect Graph (mathematics) Code Line (geometry) Word Personal digital assistant Password Order (biology) Hill differential equation Quicksort Simulation Reading (process) Reverse engineering Spacetime
Complex (psychology) Intel Presentation of a group Code Multiplication sign System administrator Range (statistics) 1 (number) Port scanner Side channel attack Magnetic stripe card Order of magnitude Software bug Mechanism design Different (Kate Ryan album) Single-precision floating-point format Encryption Endliche Modelltheorie Data conversion Physical system Email Feedback Sampling (statistics) Bit Hecke operator Data mining Type theory Order (biology) Pattern language Right angle Cycle (graph theory) Quicksort Reading (process) Resultant Asynchronous Transfer Mode Variety (linguistics) Coprocessor Number Power (physics) Twitter Latent heat Bridging (networking) Firmware Module (mathematics) Key (cryptography) Electronic program guide Projective plane Core dump Database Compiler Kernel (computing) Personal digital assistant Password Family Window
here's mr. dumbest yes all right thanks everyone let's go ahead and dive in so the fundamental premise behind this presentation is that just because we have code running at ring zero just because we have code running in the most protected privileged realm of the processor it doesn't necessarily mean that we really have accessed everything on that processor so I want to explore that idea today but first the most important part of any presentation the part the lawyers put in a disclaimer all this research is stuff I did independently this is not reflect in any way of my employer this is not their opinions this is purely my own speculation and ideas but with that out of the way my name is Christopher Thomas I'm a cybersecurity researcher I spent the last few years sort of poking around low level processor security and one of the things I really like about this is trying to find ways to expose secrets on processors things that we're not supposed to know about are not supposed to have access to so for this particular presentation I want to look at the idea of Porter called model specific registers and x86 so these registers are used for lots of different miscellaneous things things like debugging and execution tracing and performance monitoring and you can adjust your clock speed on the processor through it anis ours you can toggle thermal controls and thermal sensors and safety mechanisms on and off through MSRs you can adjust cache behavior with these model specific registers they do all sorts of miscellaneous kind of crazy things but you can dig a lot deeper than that and start to find some scary stuff that Emma SARS are sometimes responsible for for example it is known that some undocumented model specific registers can toggle really really powerful debug features on the processor there's actually really really good evidence that some firmware is using undocumented model specific registers to enable previously disabled cores on the processor and if you saw my project Rosen bridge presentation yesterday what we saw is that some MS ours are actually used for things like toggling Hardware back doors on the processor so there's some really really incredible functionality tied up in these registers that most people don't have a lot of familiarity with so it's definitely something that we want to investigate more so this is a bit of background on how you use these ms ARS before we get diving into into some really interesting facets of them they say the way ms r's work are you have to be in ring zero in order to access an MSR and then you access an MSR not by its name but by its address and ms ARS have addresses between zero and four gigabytes and only a very very small portion of that address space is actually implemented on most processors something like tens of ms ours on an order processor or hundreds on a modern processor but not many in the scheme of things and the stars are 64 bits and you read them with a read MSR assembly instruction and you write them with a rhytm asar assembly instruction so when i started looking into this what i want to figure out what sort of like well how deep do mo stars go what real functionality is there that i might be able to tinker with so i stumbled across this patent from bia that we actually looked at yesterday if you are here in this patent they casually mention that accessing some of the internal control registers they're talking about the MS ours in the situation can enable the user to bypass security mechanisms for example allowing ring 0 access at ring 3 in other words allowing you to reach into the kernel from user land something that should never be possible and they go on to say for these reasons the various x86 processor manufacturers have not publicly documented any description of the address or function of some control MSRs so that part caught my attention it's kind of like the Streisand effect right you're telling me that hey there are these really really powerful MSRs out there and we're not going to tell you anymore well of course that just makes me want to find out more about them and if we keep reading through the patent and we start to learn some other interesting things they say nevertheless the existence and locations of some of these undocumented control MSRs are easily found by programmers but typically then publish their findings for all to use specifically what they're concerned about here is people reverse engineering firm where where firmware is using these undocumented MSRs then somebody who's reverse engineering department somebody who's looking at it can very trivially see that these MS r's exist and figure out what they're being used for but from a manufacturer's perspective they've got a dilemma they want to be able to tell their customers they're our OEMs the people using their chips and building boards from their chips say one of you haven't L there murrs about these a mess ours but disclosing this information to their customers would result in the secret of these control ms ours basically becoming widely known when somebody looks at the firmware and thus being usable by anyone on any processor so this patent is actually proposing a solution to this problem there they're proposing a technique where the microprocessor itself would include a secret key manufactured internally within the microprocessor and externally invisible and this microprocessor would have encryption configured to decrypt a user supplied password using this secret key in order to generate a decrypted result in response to user instruction instructions on the microprocessor to access the control register so they're basically saying they are password protecting the read MSR and write MSR
assembly instructions for very very special powerful secret model specific registers so that's that's a little bit scary from from a security perspective right like that's that's not the way I think things should be working basically they're saying we're going to give third parties trusted keys to secret pieces of your processor and you the end user aren't going to have access to this so that's a little bit unsettling from my perspective like basically the question then is like well could my processor right now on this computer have these secret undocumented all-powerful password-protected registers in it and I don't even know because these things aren't documented anywhere because nobody knows about this it turns out the answer to that is yes this has been done before and we know this has been done before on the AMD k 7 and K 8 processors they were actually using password-protected MSR is the exact thing just described in this patent and this was discovered exactly like the patent was worried about this was discovered through firmware reverse engineering people saw these MSRs being accessed and they saw the password that firmware was using to access them now the K 7 and K 8 had a very simple password protection scheme it was just a 32-bit password loaded into a general purpose register so let's start looking at the k 7 and ka just as a case study basically let's try to treat these processors as a black box assume we didn't know this going in see if we can find a better approach to identifying password-protected registers on on x86 and I think that's important because we shouldn't have to wait until we've already been owned we shouldn't have to wait until somebody else is accessing the secrets of our processors in order to figure out that this stuff exists we should have some kind of means of detecting this kind of stuff on our own so that's what I wanted to develop a means of detecting these password-protected registers before before other people started using them so here's how things worked in AMD basically you would move a magic 32-bit value the password into the EDI register then you would move the address of the MSR that you're trying to access into the ECX register and then you would issue a read and a SAR instruction and then a couple different things could happen if that MSR that you were trying to access doesn't actually exist on the processor the CPU budget would generate what's called a general protection exception on the other hand if that MSR existed but you had the wrong password the CPU would generate a general protection exception so that's a creates a problem for our research here we get the same results in both cases in other words in order to detect that our CPU has password-protected registers that were being kept out of we have to both guess the model specific register address and guess the MSR password guessing either one of those two things wrong gives us the exact same behavior gives us a general protection exception that means we have to guess a 32-bit address and a 32-bit password we have to guess 64 bits of information correctly in order to just detect that a password-protected register exists on our processor so if you look at even the simplest embodiment of password protected registers just 32 bit passwords like AMD was using if you could make a billion such guesses per second it would take you six hundred years of processing in order to find all the password-protected registers on your processor so we need a better way we need to figure out well how could we detect that our processor has password-protected registers without actually needing to know the password first and the secret to figuring this out is sort of realizing that assembly is actually a high level abstraction underneath the hood of your processor each x86 assembly instructor is actually broken out - into microbes for execution by the CPU core so if we start thinking about what might the microcode behind a read MSR assembly instruction looked like it might look something like this underneath the hood the microcode needs to figure out what MSR you're trying to access and figure out how to give you the contents of that NSR so in my check well are you trying to access MSR number one if so it'll figure out how to handle MSR number one otherwise are you trying to access MSR six if so it'll give you the contents of MSR six etc etc until the very end if it hasn't figured out any of the existing MSR that you're trying to access that must mean that you're trying to access an MSR that doesn't exist so it throws a general protection exception you might think maybe this is implemented as a jump table we'll see some evidence coming out that this is actually can't be implemented as a jump table but that's sort of one a possible possible implementation for microcode behind that reading as our instruction so we can look at a little permutation for that to see what it might look like if microcode was trying to service a password-protected model specific register so in this situation I'm saying MSR number lead code is a password-protected MSR and I'm trying to access it so what the micro code is going to do is say well are you trying to access MSR why no MSR six nope oh you're trying to access MSR lead code well after that then into check is your password correct in this case is the EBX register feed face if so it'll service that MSR otherwise it'll throw a general protection exception so there's there's a key observation here there are two
different paths that the microcode took in order to get to the same result in both situations that ended up throwing a general protection exception but there are two different paths it took so let's look at the path that the microcode takes if I try to access an MSR that doesn't exist let's say I tried to access MSR number one two three four five six seven eight which doesn't exist on this processor it checks sorry x16 the code nope then I'm going to throw a general protection exception but let's look at the path that the microcode took if you try to access a password-protected register with the wrong password so I'm trying to access MSR lead code here but I have the wrong password here it checks MSR one six leak code okay you're accessing leak code do you have the right password no throw a general protection exception so two
different as depending on whether that or MSR existed and or whether you had the correct password so since there are two different paths here the timing on each pad should be slightly different and that opens this microcode up to a site timing side channel attack where what you can do is you can have a read MSR instruction in the middle and on either side of that read MSR instruction you have read time stamp counters in order to I'm missing something out okay that you have read time stamp counter instructions in order to detect how long that read MSR instruction took to access
so what that looks like when you actually execute on the x-axis here I have the MSR numbers that I'm trying to access on the y-axis I have the time it takes to access each MSR now the light gray lines that you see there those are the implemented MSRs I'm less interested in those for this research what I'm actually interested in is that black line along the bottom that's how long it takes to access the faulting MSRs the MSR that the processor is telling me don't really exist on this processor so what we can do with this timing side
channel attack basically I'm looking at that graph that we just generated it lets us speculate about what the underlying microcode for the Emmitt read MSR instruction must must look like specifically I can start focusing on variations in the observed fault times for accessing the various MSR so if you
look at this graph carefully if you look at this black line along the bottom what you see is that there are these discrete regions for different groups of MSRs and that sort of tells us that tells us
that the microcode must be identifying these different MSR groups prior to checking for specific MSRs in other words the model for this x86 microcode behind the read MSR instruction looks something like this it's first going to check are you trying to access an MSR between 0 and 174 if so it will figure out exactly which MSR you're accessing and service that request then it will check well are you trying to access an MSR between 174 and 200 is so it will figure out how to service that request breaking things into groups like this actually let's say it handle the read MSR instruction a lot faster than a would check you know stars one by one but if you look carefully at this model that we came up with based on that timing attack there's something a little bit unusual about two of these checks highlighted in red here two of these checks we can detect from the timings that the microcode is explicitly checking for these regions but it doesn't seem to be doing anything for those regions in both cases it just throws a general protection exception and that doesn't make a lot of sense why on earth with microcode be checking for these regions if there weren't even any visible or accessible MSRs within those regions well the only explanation for that is that there really are MSRs inside of those mysterious regions they're just not giving us access to them in other words those are probably the password-protected regions on this processor so if we if we make that assumption and we're actually able to reduce our search space rms our search space by 99.999% which actually makes cracking individual ms ours inside of those regions feasible we can essentially try all possible 32-bit values in all of the GPRS all of the MMX registers in order to crack what the password must be for those password protected registers so this works we're able to crack the passwords on the AMD k-8 and one day instead of 600 years like it would have taken without the timing attack we find that the password 9c 5a 203 a loaded into the EDI register unlocks one of those specific ranges that we detected through our timing attack that other range c00 etc that one didn't have any password-protected registers in it the microcode is doing some check on that range but there's no telling why so I do want to emphasize like this region and this password were already known people discovered this through firmer reverse engineering a while ago but this is the first time we've had an approach for uncovering these password-protected MSRs without first observing them in use and this the side channel attack into microcode offers some really powerful opportunities to really figure out what's going on under the hood of our processors things that are sort of being kept from us like these password-protected registers so the question then is like what what of it what else can we find with with an attack like this so I
started scanning a bunch of different processors using this MSR timing technique and wanted to share some of those results with you quickly so here's what we found on a newer AMD processor it no longer has some of the timing dips that the KA had which kind of suggests that newer processor or newer AMD's got rid of this password check here's a via c3 scan where they didn't have any unusual timings on faulting registers but they had these two enormous spikes at 133 and one 133 those at massage took over a hundred thousand cycles to access there is no feasible explanation for why reading and NSR should take over a hundred thousand cycles that's three orders of magnitude longer than the next log longest MSR took to access that's evil time to be doing encryption or any other number of interesting things so that definitely warrants some more scrutiny the VM Yano had this interesting spike on the left where inexplicably a small range of MSRs seemed to be protected until Adams Intel Core i5 also had some interesting timing patterns where you can see these little blips in the fault times where basically I'm asking the processor does this MS artist it says note does this one exist no does this exist no does this exist and it thinks for a little bit and says no it's like well if it didn't exist just like all the ones right around it why did you have to think for a little bit in order to respond so it's it's really interesting behavior and it made me nervous seeing these these blips at
the end of the day I tried running my password cracking approach on this and I failed I tried a lot of different things to crack 64-bit passwords I tried other types of side-channel attacks in order to detect more complex password mechanisms I wasn't able to uncover any new passwords this way and sometimes that's just the way research turns out but we're still left with this glaring question almost all these processors had weird timing anomalies within the micro code and we don't have any other way to see what the micro code is doing so we're left to speculate so what is causing these timing anomalies well there's a lot of possibilities I'm one to be or advance password checks that's exactly what that via patent that we looked at at the beginning of the presentation was describing it could be something like that it could be that some of these MSRs are only accessible in ultra privileged modes like some MSRs are only accessible in system management mode Intel as patents on MSR that are only accessible to authenticated code modules or could be something benign for example it could be that the micro code is checking the processor family the model is stepping basically what that would do what it would allow you to use one micro code update on a variety of different processor families so that's that's possible too and in fact it kind of looked like that was probably what was happening on the Intel processors those little blips actually seemed to align with documented MSRs on the other processor families but so so it's kind of nice to think well maybe we're in the clear maybe password protected registers don't really exist beyond the k7 and k-8 since we couldn't find anything here but sadly that's that's not the case at the end of this research I had a friend of mine send me his x86 firmware database and I wrote a little instruction grepping tool to look through for certain assembly instruction patterns I mean I was very quickly able to find a new previously undisclosed MSR password 3/8 OD z BOF and the ESI register is an MSR password being used by hundreds of different firmwares across many different vendors you can even find its magic number being used to access MSRs in the Windows kernel but nobody in the public has ever seen this so we are still in a situation where third parties are being given keys to our processors that we ourselves do not possess I think are the are cracked our password scanning tool that I introduced here didn't find us because I only had so many processors at my disposal I scanned 12 processors I found 11 with timing anomalies but that's obviously not every processor out there so more scans need can be done to figure out exactly what this is being used for it's sort of an open question right now so at the end of the day I really think this research is interesting but we've raised a lot more questions than we've answered we've found a really interesting timing attack and we found some suspicious things and I think the stakes here are really real hi it's clear MSRs are being used for lots of powerful things they control all the details of your processor and until now nobody's ever had ways to look into what they were actually doing so I think this research is really promising this timing side channel attack on specific assembly instructions is entirely new and gets us a really cool way to sort of uncover some processor secrets that nobody's ever found before so I'm excited about that what I really like is for people to use this and scan their own processors I'm open sourcing this as project nightshift you can find us on github github calm slash X or e ax ax e ax I haven't been able to get that up yet but that should be up probably by Monday what I would really love is for people to run the scan on their systems send me the logs so that we can sort of collect a database of processors that have these unusual timing anomalies and maybe when we get enough samples we can actually figure out what the heck is going on on some of these systems other stuff you can find their project rotors and bridges to backdoor that I talked about yesterday if you were around stance if there's a processor fuzzer obfuscators and interesting single instruction c compiler and some other stuff i've I've tinkered with over the years I love talking about this stuff if anybody has feedback or ideas that they'd like to discuss I'm gonna have to step out to let make room for the next speaker but please grab me out the door here otherwise you can contact me on Twitter at X or e ax e ax ax or if you want to have more Provost conversation please do send me an email same thing at so thank you everybody I'll be right outside [Applause]