*36C3 preroll music*
Herald Angel: OK. Welcome to our next talk. It's called flipping bits from
software without Row hammer, small reminder Row hammer used, still is a
software based fault attack. It was published in 2015. There were
countermeasures developed and we are still in the process of deploying these
everywhere. And now our two speakers are going to talk about a new software based
fault attack to execute commands inside the SGX environment. Our speakers,
Professor Daniel Gruss from the University of Graz and Kit Murdoch researching at the
University of Birmingham. The content of this talk is actually in her first
published paper published at IEEE, no accepted at IEEE Security and Privacy next
year. In case you do not come from the academic world, if this is your this is
always a big deal. If this is your first paper, it even more is, please welcome
them, both of you get a round of applause and enjoy the talk.
*Applause*
Kit Murdoch: Thank you. Hello. Let's get started. This is my favorite recent
attack. It's called Clockscrew. And the reason that it's my favorite is it created
a new class of fault attacks. Daniel Gruss: Fault attacks. I, I know that.
Fault attacks, you take these oscilloscopes and check the voltage line
and then you drop the voltage for a f.... Kit: No, you see, this is why this one is
cool because you don't need any equipment at all. Adrian Tang. He created this
wonderful attack that uses DVFS. What is that?
Daniel: DVFS ? I don't know, don't violate format specifications.
Kit: I asked my boyfriend this morning what he thought DVFS stood for and he said
Darth Vader fights Skywalker. *Laughter*
Kit: I'm also wearing his t-shirt specially for him as well.
Daniel: Maybe, maybe this is more technical, maybe dazzling volt for
security like SGX. Kit: No, it's not that either. Mine was,
the one I came up this morning was: Drink vodka feel silly.
*Laughter* Kit: It's not that either. It stands for
dynamic voltage and frequency scaling. And what that means really simply is changing
the voltage and changing the frequency of your CPU. Why do you want to do this? Why
would anyone want to do this? Well, gamers want fast computers. I am sure there are a
few people out here who will want a really fast computer. Cloud Servers want high
assurance and low running costs. And what do you do if your hardware gets hot?
You're going to need to modify them. And actually finding a voltage and frequency
that work together is pretty difficult. And so what the manufacturers have done to
make this easier, is they've created a way to do this from software. They created
memory mapped registers. You modify this from software and it has an impact on the
hardware. And that's what this wonderful clockscrew attack did. But they found
something else out, which is you may have heard of: trust zone. Trust zone is in an
enclave in ARM chips that should be able to protect your data. But if you can
modify the frequency and voltage of the whole core, then you can modify it for
both trust zone and normal code. And this is their attack. In software they modified
the frequency to make it outside of the normal operating range. And they induced
faults. And so in an arm chip running on a mobile phone, they managed to get out an
AES key from within trust zone. They should not be able to do that. They were
able to trick trust zone into loading a self-signed app. You should not be able to
do that. That made this ARM attack really interesting. This year another attack came
out called volt jockey. This also attacked ARM chips. But instead of looking at
frequency on ARM chips, they were looking at voltage on ARM chips. We're thinking,
what about Intel? Daniel: OK, so Intel. Actually, I know
something about Intel because I had this nice laptop from HP. I really liked it,
but it had this problem that it was going too hot all the time and I couldn't even
work without it shutting down all the time because of the heat problem. So what I did
was I undervolted the CPU and actually this worked for me for several years. I
used this undervolted for several years. You can also see this, I just took this
from somewhere on the Internet and they compared with undervolting and without
undervolting. And you can see that the benchmark score improves by undervolting
because you don't run into the thermal throttling that often. So there are
different tools to do that. On Windows you could use RMClock, there's also
Throttlestop. On Linux there's the Linux- intel-undervolt GitHub repository.
Kit: And there's one more, actually. Adrian Tang, who I don't know if you know
a bit of a fan. He was the lead author on Clocks Screw. He wrote his PhD Thesis and
in the appendix he talked about undervolting on Intel machines and how you
do it. And I wish I'd read that before I started the paper. That would have saved
an awful lot of time. But thank you to the people on the Internet for making my life
a lot easier, because what we discovered was there is this magic module specific
register and it's called Hex 150. And this enables you to change the voltage the
people on the Internet did the work for me. So I know how it works. You first of
all tell it the plain RDX, what it is you want to, raise the voltage or lower the
voltage. We discovered that the core and the cache are on the same plane. So you
have to modify them both. But it has no effect, they're together. I guess in the
future they'll be separate. Then you modify the offset to say, I want to raise
it by this much or lower it by this much. So I thought, let's have a go. Let's write
a little bit of code. Here is the code. The smart people amongst you may have
noticed something. I suspect even my appalling C, even I would recognize that
that loop should never exit. I'm just multiplying the same thing again and again
and again and again and again and expecting it to exit. That shouldn't
happen. But let's look at what happened. So I'm gonna show you what I did. Oh..
There we go. So the first thing I'm gonna do is I'm going to set the frequency to be
one thing because I'm gonna play with voltage and if I'm gonna play with
voltage, I want the frequency to be set. So, It's quite easy using cpupower,
you set the maximum and the minimum to be 1 gigahertz. And now my machine is running
at exactly 1 gigahertz. Now we'll look at the bit of code that you need to
undervolt, again I didn't do the work, thank you to the people on the internet
for doing this. You put the MSR into the kernel and let's have a look at the code.
Does that look right? Oh, it does, looks much better up there. Yes, it's that one
line of code. That is the one line of code you need to open and then we're going to
write to it. And again, oh why is it doing that? We have a touch sensitive screen
here. Might touch it again. That's the line of code that's gonna open it and
that's how you write to it. And again, the people on the Internet did the work for me
and told me how I had to write that. So what I can do here is I'm just going to
undervolt and I'm gonna undervolt, multiplying deadbeef by this really big
number. I'm starting at minus two hundred and fifty two millivolts. And we're just
going to see if I ever get out of this loop.
Daniel: But surely the system would just crash, right?
Kit: You'd hope so, wouldn't you? Let's see, there we go! We got a fault. I was a
bit gobsmacked when that happened because the system didn't crash.
Daniel: So that doesn't look too good. So the question now is, what is the... So you
show some voltage here, some undervolting. Kit: Yeah
Daniel: What undervolting is actually required to get a bit flip?
Kit: We did a lot of tests. We didn't just multiply by deadbeef. We also multiplied
by random numbers. So here I'm going to just generate two random numbers. One is
going up to f f f f f f one is going up to ff. I'm just going to try different, again
I'm going to try undervolting to see if I get different bit flips. And again, I got
the same bit flipped, so I'm getting the same one single bit flip there. Okay, so
maybe it's only ever going to be one bit flip. Ah, I got a different bit flip and
again a different bit flip and it's, you'll notice they always appear to be
bits together next to one another. So to answer Daniel's question, I pressed my
machine a lot in the process of doing this, but I wanted to know what were good
values to undervolt at. And here they are. We tried for all the frequencies. We tried
what was the base voltage? And then when was the point at which we got the first
fault? And once we'd done that, it made everything really easy. We just made sure
we didn't go under that and ended up with a kernel panic or the machine crashing.
Daniel: So this is already great. I think this looks like it is exploitable and the
first thing that you need when you are working on a vulnerability is the name and
the logo and maybe a Website. Everything like that. And real people on the Internet
agree with me. Like this tweet. *Laughter*
Daniel: Yes. So we need a name and a logo. Kit: No, no, we don't need it. Come on.
then. Go on then. What is your idea? Daniel: So I thought this is like, it's
like Row hammer. We are flipping bits, but with voltage. So I called it Volt hammer
and I already have a logo for it. Kit: We're not, we're not giving it a
logo. Daniel: No, I think we need a logo because
people can relate more to the images there, to the logo that we have. Reading a
word is much more complicated than seeing a logo somewhere. It's better for
communication. You make it easier to talk about your vulnerability. Yeah? And the
name, same thing. How, how would you like to call it? Like undervolting on Intel to
induce flips in multiplications to then run an exploit? No, that's not a good
vulnerability name. And speaking of the name, if we choose a fancy name, we might
even make it into TV shows like Row hammer.
Video Clip 1A: The hacker used a DRAM Row hammer exploit to gain kernel privileges.
Video Clip 1B: HQ, yeah we've got something.
Daniel: So this was in designated Survivor in March 2018 and this guy just got shot.
So hopefully we won't get shot but actually we have also been working. So my
group has been working on Row hammer and presented this in 2015 here at CCC, in
Hamburg back then. It was Row hammer JS and we called it root privileges for web
apps because we showed that you can do this from JavaScript in a browser. Looks
pretty much like this, we hammered the memory a bit and then we see a bit flips
in the memory. So how does this work? Because maybe for another fault attack,
software based fault attack, the only other software based fault attack that we
know. So, these are related to DFS and this is a different effect. So what do we
do here is we look at the DRAM and the DRAM is organized in multiple rows and we
will access these rows. These rows consist of so-called cells, which are capacitors
and transistors each. And they store one bit of information each. And the row
buffer, the row size usually is something like eight kilobytes. And then when you
read something, you copy it to the row buffer. So it works pretty much like this:
You read from a row, you copy it to the row buffer. The problem now is, these
capacitors leak over time so you need to refresh them frequently. And they have
also a maximum refresh interval defined in a standard to guarantee data integrity.
Now the problem is that cells leak fast upon proximate accesses, and that means if
you access two locations in proximity to a third location, then the third location
might flip a bit without accessing it. And this has been exploited in different
exploits. So the usual strategies is maybe, maybe we can use some of them. So
the usual strategies here are searching for a page with a bit flip. So you search
for it and then you find some. Ah, There is a flip here. Then you release the page
with the flip in the next step. Now this memory is free and now you allocate a lot
of target pages, for instance, page tables, and then you hope that the target
page is placed there. If it's a page table, for instance, like this and you
induce a bit flip. So before it was pointing to User page, then it was
pointing to no page at all because we maybe unmapped it. And the page that we
use the bit flip now is actually the one storing all of the PTEs here. So the one
in the middle is stored down there. And this one now has a bit flip and then our
pointer to our own user page changes due to the big flip and points to hopefully
another page table because we filled that memory with page tables. Another direction
that we could go here is flipping bits in code. For instance, if you think about a
password comparison, you might have a jump equal check here and the jump equal check
if you flip one bit, it transforms into a different instruction. And fortunately, oh
this already looks interesting. Ah, Perfect. Changing the password check nto a
password incorrect check. I will always be root. And yeah, that's basically it. So
these are two directions that we might look at for Row hammer. That's also maybe
a question for Row hammer, why would we even care about other fault attacks?
Because Row hammer works on DDR 3, it works on DDR 4, it works on ECC memory.
Kit: Does it, how does it deal with SGX? Daniel: Ahh yeah, yeah SGX. Ehh, yes. So
maybe we should first explain what SGX is. Kit: Yeah, go for it.
Daniel: SGX is a so-called TEE trusted execution environment on Intel processors
and Intel designed it this way that you have an untrusted part and this runs on
top of an operating system, inside an application. And inside the application
you can now create an enclave and the enclave runs in a trusted part, which is
supported by the hardware. The hardware is the trust anchor for this trusted enclave
and the enclave, now you can from the untrusted part, you can call into the
enclave via a Callgate pretty much like a system call. And in there you execute a
trusted function. Then you return to this untrusted part and then you can continue
doing other stuff. And the operating system has no direct access to this
trusted part. This is also protected against all kinds of other attacks. For
instance, physical attacks. If you look at the memory that it uses, maybe I have 16
gigabytes of RAM. Then there is a small region for the EPC, the enclave page
cache, the memory that enclaves use and it's encrypted and integrity protected and
I can't tamper with it. So for instance, if I want to mount a cold boot attack,
pull out the DRAM, put it in another machine and read out what content it has.
I can't do that because it's encrypted. And I don't have the key. The key is in
the processor quite bad. So, what happens if we have bit flips in the EPC? Good
question. We tried that. The integrity check fails. It locks up the memory
controller, which means no further memory accesses whatsoever run through this
system. Everything stays where it is and the system halts basically. It's no
exploit, it's just denial of service. Kit: Huh. So maybe SGX can save us. So
what I want to know is, Row Hammer clearly failed because of the integrity check. Is
my attack where I can flip bits. Is this gonna work inside SGX?
Daniel: I don't think so because they have integrity protection, right?
Kit: So what I'm gonna do is run the same thing in the right hand side is user
space. In the left hand side is the enclave. As you can see, I'm running at
minus 261 millivolts. No error minus 262. No error minus 2... fingers crossed we
don't get a kernel panic. Do you see that thing at the bottom? That's a bit flip
inside the enclave. Oh, yeah. Daniel: That's bad.
*Applause* Kit: Thank you. Yeah and it's the same
bit flip that I was getting in user space , that is also really interesting.
Daniel: I have an idea. So, it's surprising that it works right. But I have
an idea. This is basically doing the same thing as clocks group. But on SGX, right?
Kit: Yeah. Daniel: And I thought maybe you didn't
like the previous logo, maybe it was just too much. So I came up with something more
simple... Kit: You've come up with a new... He's
come up with a new name. Daniel: Yes, SGX Screw. How do you like
it? Kit: No, we don't even have an attack. We
can't have a logo before we have an attack.
Daniel: The logo is important, right? I mean, how would you present this on a
website without a logo?
Kit: Well, first of all, I need an attack. What am I going to attack with this?
Daniel: I have an idea what we could attack. So, for instance, we could attack
crypto, RSA. RSA is a crypto algorithm. It's a public key crypto algorithm. And
you can encrypt or sign messages. You can send this over an untrusted channel. And
then you can also verify. So this is actually a typo which should be decrypt...
there, encrypt verifying messages with a public key or decrypt sign messages with a
private key. So how does this work? Yeah, basically it's based on exponention modulo a
number and this number is computed from two prime numbers. So you, for the
signature part, which is similar to the decryption basically, you take the hash of
the message and then take it to the power of d modulo n, the public modulus, and
then you have the signature and everyone can verify that this is actually, later on
can verify this because the exponent part is public. So n is also public so we can
later on do this. Now there is one optimization which is quite nice, which is
Chinese remainder theorem. And this part is really expensive. It takes a long time.
So it's a lot faster, if you split this in multiple parts. For instance, if you split
it in two parts, you do two of those exponentations, but with different
numbers, with smaller numbers and then it's cheaper. It takes fewer rounds. And if you
do that, you of course have to adapt the formula up here to compute the signature
because, you now put it together out of the two pieces of the signature that you
compute. OK, so this looks quite complicated, but the point is we want to
mount a fault attack on this. So what happens if we fault this? Let's assume we
have two signatures which are not identical. Right, S and S', and we
basically only need to know that in one of them, a fault occurred. So the first is
something, the other is something else. We don't care. But what you see here is that
both are multiplied by Q plus s2. And if you subtract one from the other, what do
you get? You get something multiplied with Q. There is something else that is
multiplied with Q, which is P and n is public. So what we can do now is we can
compute the greatest common divisor of this and n and get q.
Kit: Okay. So I'm interested to see if... I didn't understand a word of that, but
I'm interested to see if I can use this to mount an attack. So how am I going to do
this? Well, I'll write a little RSA decrypt program and what I'll do is I use
the same bit of multiplication that I've been using before. And when I get a bit
flip, then I'll do the decryption. All this is happening inside SGX, inside the
enclave. So let's have a look at this. First of all, I'll show you the code that
I wrote, again copied from the Internet. Thank you. So there it is, I'm going to
trigger the fault.I'm going to wait for the triggered fault, then I'm going to do
a decryption. Well, let's have a quick look at the code, which should be exactly
the same as it was right at the very beginning when we started this. Yeah.
There's my deadbeef written slightly differently. But there is my deadbeef. So,
now this is ever so slightly messy on the screen, but I hope you're going to see
this. So minus 239. Fine. Still fine. Still fine. I'll just pause there. You can
see at the bottom I've written meh - all fine., If you're wondering. So what we're
looking at here is a correct decryption and you can see inside the enclave, I'm
initializing p and I'm initializing q. And those are part of the private key. I
shouldn't be able to get those. So 239 isn't really working. Let's try going up
to minus 240. Oh oh oh oh! RSA error, RSA error. Exciting!
Daniel: Okay, So this should work for the attack then.
Kit: So let's have a look, again. I copied somebodys attack on the Internet where
they very kindly, It's called the lenstra attack. And again, I got I got an output.
I don't know what it is because I didn't understand any of that crypto stuff.
Daniel: Me neither. Kit: But let me have a look at the source
code and see if that exists anywhere in the source code inside the enclave. It
does. I found p. And if I found p, I can find q. So just to summarise what I've
done, from a bit flip I have got the private key out of the SGX enclave and I
shouldn't be able to do that. Daniel: Yes, yes and I think I have an
idea. So you didn't like the previous... Kit: Ohh, I know where this is going. Yes.
Daniel: ...didn't like the previous name. So I came up with something more cute and
relatable, maybe. So I thought, this is an attack on RSA. So I called it Mufarsa.
*Laughter* Daniel: My Undervolting Fault Attack On
RSA. Kit: That's not even a logo. That's just a
picture of a lion. Daniel: Yeah, yeah it's, it's sort of...
Kit: Disney are not going to let us use that.
*Laughter* Kit: Well it's not, is it Star Wars? No,
I don't know. OK. OK, so Daniel, I really enjoyed it.
Daniel: I don't think you will like any of the names I suggest.
Kit: Probably not. But I really enjoyed breaking RSA. So what I want to know is
what else can I break? Daniel: Well...
Kit: Give me something else I can break. Daniel: If you don't like the RSA part, we
can also take other crypto. I mean there is AES for instance, AES is a symmetric
key crypto algorithm. Again, you encrypt messages, you transfer them over a public
channel, this time with both sides having the key. You can also use that for
storage. AES internally uses a 4x4 state matrix for 4x4 bytes and it runs through
ten rounds which are S-box, which basically replaces a byte by another byte,
some shifting of rows in this matrix, some mixing of the columns, and then the round
keys is added which is computed from the AES key that you provided to the
algorithm. And if we look at the last three rounds because we want to, again,
mount a fault attack, and there are different differential fault attacks on
AES. If you look at the last rounds, because the way of this algorithm works is
it propagates, changes, differences through this algorithm. If you'd look at
the state matrix, which only has a difference in the top left corner, then
this is how the state will propagate through the 9th and 10th round. And you
can put up formulas to compute possible values for the state up there. If you have
different, if you have encryption, which only have a difference there in exactly
that single state byte. Now, how does this work in practice? Well, today everyone is
using AES-NI because that's super fast. That's, again, an instruction set
extension by Intel and it's super fast. Kit: Oh okay, I want to have a go. Right,
so let me have a look if I can break some of these AES-NI instructions. So I'm to
come at this slightly differently. Last time I waited for a multiplication fault,
I'm going to do something slightly different. What I'm going to do is put in
a loop two AES encryptions. And I wrote this using Intel's code, I should say I we
wrote this using Intel's code, example code. This should never fault. And we know
what we're looking for. What we're looking for is a fault in the eighth round. So
let's see if we get faults with this. So the first thing is I'm going to start at
minus 262 millivolt. What's interesting is that you have to undervolt more when it's
cold so you can tell at what time of day I ran these. Oh I got a fault, I got a fault.
Well, unfortunately. Where did that? That's actually in the fourth round. I'm
I'm obviously, eh fifth round, okay. Daniel: You can't do anything with that.
Kit: You can't do anything, again in the fifth round. Can't do anything with that,
fifth round again. Oh! Oh we got one. We got one in the eighth round. And so it
means I can take these two ciphertext and I can use the differential fault attack. I
actually ran this twice in order to get two pairs of faulty output because it made
it so much easier. And again, thank you to somebody on the Internet for having
written a differential fault analysis attack for me. You don't, you don't need
two, but it just makes it easy for the presentation. So I'm now going to compare.
Let me just pause that a second, I used somebody else's differential fault attack
and it gave me in one, for the first pair it gave me 500 possible keys and for the
second it gave me 200 possible keys. I'm overlapping them. And there was only one
key that matched both. And that's the key that came out. And let's just again check
inside the source code, does that key exist? What is the key? And yeah, that is
the key. So, again what I've... Daniel: That is not a very good key,
though. Kit: No, Ehhh... I think, if you think
about randomness, it's as good as any other. Anyway, ehhh...
*Laughter* Kit: What have I done? I have flipped a
bit inside SGX to create a fault in AES New Instruction set that has enabled me to
get the AES key out of SGX. You shouldn't be able to do that.
Daniel: So. So now that we have multiple attacks, we should think about a logo and
a name, right? Kit: This one better be good because the
other one wasn't very good. Daniel: No, seriously, we are already
soon... Kit: Okay.
Daniel: We are, we will write this out. Send this to a conference. People will
like it, right. This is and I already have a name and a logo for it. Kit: Come on
then. Daniel: Crypto Vault Screw Hammer.
*Laughter* Daniel: It's like, we attack crypto in a
vault, SGX, and it's like a, like the Clock screw and like Row hammer. And
like... Kit: I don't think that's very catchy. But
let me tell you, it's not just crypto. So we're faulting multiplication. So surely
there's another use for this other than crypto. And this is where something really
interesting happens. For those of you who are really good at C you can come and
explain this to me later. This is a really simple bit of C. All I'm doing is getting
an offset of an array and taking the address of that and putting it into a
pointer. Why is this interesting? Hmmm, It's interesting because I want to know
what the compiler does with that. So I am going to wave my magic wand and what the
compiler is going to do is it's going to make this. Why is that interesting?
Daniel: Simple pointer arithmetic? Kit: Hmmm. Well. we know that we can fault
multiplications. So we're no longer looking at crypto. We're now looking at
just memory. So let's see if I can use this as an attack. So let me try and
explain what's going on here. On the right hand side, you can see the undervolting.
I'm going to create an enclave and I've put it in debug mode so that I can see
what's going on. You can see the size of the enclave because we've got the base and
the limit of it. And if we look at that in a diagram, what that's saying is here. If
I can write anything at the top above that, that will no longer be encrypted,
that will be unencrypted. Okay, let's carry on with that. So, let's just write
that one statement again and again, that pointer arithmetic again and again and
again whilst I'm undervolting and see what happens. Oh, suddenly it changed and if
you look at where it's mapped it to, it has mapped that pointer to memory that is
no longer inside SGX, it has put it into untrusted memory. So we're just doing the
same statement again and again whilst undervolting. Besh, we've written
something that was in the enclave out of the enclave. And I'm just going to display
the page of memory that we've got there to show you what it was. And there's the one
line, it's deadbeef And again, I'm just going to look in my source code to see
what it was. Yeah, it's, you know you know, endianness blah, blah, blah. I have
now not even used crypto. I have purely used pointer arithmetic to take something
that was stored inside Intel's SGX and moved it into user space where anyone can
read it. Daniel: So, yes, I get your point. It's
more than just crypto, right? Kit: Yeah.
Daniel: It's way beyond that. So we, we leaked RSA keys. We leaked AES keys.
Kit: Go on... Yeah, we did not just that though we did memory corruption.
Daniel: Okay, so. Yeah. Okay. Crypto Vault Screw Hammer, point taken, is not the
ideal name, but maybe you could come up with something. We need a name and a logo.
Kit: So pressures on me then. Right, here we go. So it's got to be due to
undervolting because we're undervolting. Maybe we can get a pun on vault and volt
in there somewhere. We're stealing something, aren't we? We're corrupting
something. Maybe. Maybe we're plundering something.
Daniel: Yeah? Kit: I know.
Daniel: No?
Kit: Let's call it plunder volt. Daniel: Oh, no, no, no. That's not it.
That's not a good nane. Kit: What?
Daniel: That, no. We need something... That's really not a good name. People will
hate this name. Kit: Wait, wait, wait, wait, wait.
Daniel: No... *Laughter*
Kit: You can read this if you like, Daniel.
Daniel: Okay. I, I think I get it. I, I think I get it.
Kit: No, no, I haven't finished. *Laughter*
Daniel: Okay. Yeah, this is really also a very nice comment. Yes. The quality of the
videos, I think you did a very good job there.
Kit: Thank you. Daniel: Also, the website really good job
there. Kit: So, just to summarize, what we've
done with plunder volt is: It's a new type of attack, it breaks the integrity of SGX.
It's within SGX. We're doing stuff we shouldn't be able to.
Daniel: Like AES keys, we leak AES keys, yeah.
Kit: And we are retrieving the RSA signature key.
Daniel: Yeah. And yes, we induced memory corruption in bug free code.
Kit: And we made the Enclave write Secrets to untrusted memory. This is the paper,
that's been accepted next year. It is my first paper, so thank you very much. Kit,
that's me. *Applause*
Kit: Thank you. David Oswald, Flavio Garcia, Jo Van Bulck and of course, the
infamous and Frank Piessens. So all that really remains for me to do is to say,
thank you very much for coming... Daniel: Wait a second, wait a second.
There's one more thing, I think you overlooked one of the tweets I added it
here. You didn't see this slide yet? Kit: I haven't seen this one.
Daniel: This one, I really like it. Kit: It's a slightly ponderous pun on
Thunderbolt... pirate themed logo. Daniel: A pirate themed logo. I really
like it. And if it's a pirate themed logo, don't you think there should be a pirate
themed song? *Laughter*
Kit: Daniel, have you written a pirate theme song? Go on then, play it. Let's,
let's hear the pirate theme song. *music* -- see screen --
Music: ...Volt down me enclaves yo ho. Aye but it's fixed with a microcode patch.
Volt down me enclaves yo ho. Daniel: Thanks to...
*Applause* Daniel: Thanks to Manuel Weber and also to
my group at Theo Graz for volunteering for the choir.
*Laughter* Daniel: And then, I mean, this is now the
last slide. Thank you for your attention. Thank you for being here. And we would
like to answer questions in the Q&A
*Applause*
Herald: Thank you for your great talk. And thank you some more for the song. If you
have questions, please line up on the microphones in the room. First question
goes to the signal angel, any question from the Internet?
Signal-Angel: Not as of now, no. Herald: All right. Then, microphone number
4, your question please. Microphone 4: Hi. Thanks for the great
talk. So, why does this happen now? I mean, thanks for the explanation for wrong
number, but it wasn't clear. What's going on there?
Daniel: So, too, if you look at circuits for the signal to be ready at the output,
they need, electrons have to travel a bit. If you increase the voltage, things will
go faster. So they will, you will have the output signal ready at an earlier point in
time. Now the frequency that you choose for your processor should be related to
that. So if you choose the frequency too high, the outputs will not be ready yet at
this circuit. And this is exactly what happens, if you reduce the voltage the
outputs are not ready yet for the next clock cycle.
Kit: And interestingly, we couldn't fault really short instructions. So anything
like an add or an xor, it was basically impossible to fault. So they had to be
complex instructions that probably weren't finishing by the time the next clock tick
arrived. Daniel: Yeah.
Microphone 4: Thank you. Herald: Thanks for your answer. Microphone
number 4 again. Microphone 4: Hello. It's a very
interesting theoretical approach I think. But you were capable to break these crypto
mechanisms, for example, because you could do zillions of iterations and you are sure
to trigger the fault. But in practice, say, as someone is having a secure
conversation, is it practical, even close to a possible too to break it with that?
Daniel: It totally depends on your threat model. So what can you do with the
enclave? If you, we are assuming that we are running with root privileges here and
a root privileged attacker can certainly run the enclave with certain inputs, again
and again. If the enclave doesn't have any protection against replay, then certainly
we can mount an attack like that. Yes. Microphone 4: Thank you.
Herald: Signal-Angel your question. Signal: Somebody asked if the attack only
applies to Intel or to AMD or other architectures as well.
Kit: Oh, good question, I suspect right now there are people trying this attack on
AMD in the same way that when clock screw came out, there were an awful lot of
people starting to do stuff on Intel as well. We saw the clock screw attack on ARM
with frequency. Then we saw ARM with voltage. Now we've seen Intel with
voltage. And someone else has done similar Volt pwn has done something very similar
to us. And I suspect AMD is the next one. I guess, because it's not out there as
much. We've tried to do them in the order of, you know, scaring people.
*Laughter* Kit: Scaring as many people as possible as
quickly as possible. Herald: Thank you for the explanation.
Microphone number 4. Microphone 4: Hi. Hey, great. Thanks for
the representation. Can you get similar results by Harrower? I mean by tweaking
the voltage that you provide to the CPU or...
Kit: Well, I refer you to my earlier answer. I know for a fact that there are
people doing this right now with physical hardware, seeing what they can do. Yes,
and I think it will not be long before that paper comes out.
Microphone 4: Thank you. Herald: Thanks. Microphone number one.
Your question. Sorry, microphone 4 again, sorry.
Microphone 4: Hey, thanks for the talk. Two small questions. One, why doesn't
anything break inside SGX when you do these tricks? And second one, why when you
write outside the enclaves memory, their value is not encrypted.
Kit: So the enclave is an encrypted area of memory. So when it points to an
unencrypted, it's just going to write it to the unencrypted
memory. Does that make sense? Daniel: From the enclaves perspective,
none of the memory is encrypted. This is just transparent to the enclave. So if the
enclave will write to another memory location. Yes, it just won't be encrypted.
Kit Yeah. And what's happening is we're getting flips in the registers. Which is
why I think we're not getting an integrity check because the enclave is completely
unaware that anything's even gotten wrong. It's got a value in its memory and it's
gonna use it. Daniel: Yeah. The integrity check is only
on the on the memory that you logged from RAM. Yeah.
Herald: Okay, microphone number 7. Microphone 7: Yeah. Thank you. Interesting
work. I was wondering, you showed us the example of the code that wrote outside the
Enclave Memory using simple pointer arithmetics. Have you been able to talk to
Intel why this memory access actually happens? I mean, you showed us the output
of the program. It crashes, but nevertheless, it writes the result to the
resulting memory address. So there must be something wrong, like the attack that
happened two years ago at the Congress about, you know, all that stuff.
Daniel: So generally enclaves can read and write any memory location in their host
application. We have also published papers that basically argued that this might not
be a good idea, good design decision. But that's the current design. And the reason
is that this makes interaction with the enclave very easy. You can just place your
payload somewhere in the memory. Hand the pointer to the enclave and the enclave can
use the data from there, maybe copy it into the enclave memory if necessary, or
directly work on the data. So that's why this memory access to the normal memory
region is not illegal. Kit: And if you want to know more, you can
come and find Daniel afterwards. Herald: Okay. Thanks for the answer.
Signal-Angel, the questions from the Internet.
Signal-Angel: Yes. The question came up. If, how stable the system you're attacking with
the hammering is while you're performing their attack.
Kit: It's really stable. Once I've been through three months of crashing the
computer. I got to a point where I had a really, really good frequency voltage
combination. And we did discover on all Intel chips, it was different. So even, on
what looked like and we bought almost an identical little nook, we bought one with
exactly the same spec and it had a different sort of frequency voltage model.
But once we'd done this sort of benchmarking, you could pretty much do any
attack without it crashing at all. Daniel: But without this benchmarking,
it's true. We would often reboot. Kit: That was a nightmare yeah, I wish I'd
done that the beginning. It would've saved me so much time.
Herald: Thanks again for answering. Microphone number 4 your question.
Microphone 4: Can Intel fix this with a microcode update?
Daniel: So, there are different approaches to this. Of course, the quick fix is to
remove the access to the MSR, which is of course inconvenient because you can't
undervolt your system anymore. So maybe you want to choose whether you want to use
SGX or want to have a gaming computer where you undervolt the system or control
the voltage from software. But is this a real fix? I don't know. I think there are
more vectors, right? Kit: Yeah.But, well I'll be interested to
see what they're going to do with the next generation of chips.
Daniel: Yeah. Herald: All right. Microphone number 7,
what's your question? Microphone 7: Yes, similarly to the other
question, is there a way you can prevent such attacks when writing code that runs
in the secure enclave? Kit: Well, no. That's the interesting
thing, it's really hard to do. Because we weren't writing code with bugs, we were
just writing normal pointer arithmetic. Normal crypto. If anywhere in your code,
you're using a multiplication. It can be attacked.
Daniel: But of course, you could use fault resistant implementations inside the
enclave. Whether that is a practical solution is yet to be determined
Kit: Oh yes, yea, right, you could write duplicate code and do comparison things
like that. But if, yeah. Herald: Okay. Microphone number 3. What's
your question?
Microphone 3: Hi. I can't imagine Intel being very happy about this and recently
they were under fire for how they were handling a coordinated disclosure. So can
you summarize experience? Kit: They were... They were really nice.
They were really nice. We disclosed really early, like before we had all of the
attacks. Daniel: We just had a POC at that point.
Kit: Yeah. Daniel: Yeah, Simply POC. Very simple.
Kit: They've been really nice. They wanted to know what we were doing. They wanted to
see all our attacks. I found them lovely. Daniel: Yes.
Kit: Am I allowed to say that? *Laughter*
Daniel: I mean, they also have interest in...
Kit: Yeah. Daniel ...making these processes smooth.
So that vulnerability researchers also report to them.
Kit: Yeah. Daniel: Because if everyone says, oh this
was awful, then they will also not get a lot of reports. But if they do their job
well and they did in our case. Kit: Yeah.
Daniel: Then of course, it's nice. Herald: Okay. Microphone number 4...
Danie: We even got a bug bounty. Kit: We did get a bug bounty. I didn't
want to mention that because I haven't told my university yet.
*Laughter* Microphone 4: Thank you. Thank you for the
funny talk. If I understood, you're right, it means to really be able to exploit
this. You need to do some benchmarking on the machine that you want to exploit. Do
you see any way to convert this to a remote exploit? I mean, that to me, it
seems you need physical access right now because you need to reboot the machine.
Kit: If you've done benchmarking on an identical machine, I don't think you would
have to have physical access. Daniel: But you would have to make sure
that it's really an identical machine. Kit: Yeah.
Daniel: But in the cloud you will find a lot of identical machines.
*Laughter* Herald: Okay, microphone number 4 again.
Daniel: Also, as we said, like the temperature plays an important role.
Kit: Yeah. Daniel: You will also in the cloud find a
lot of machines at similar temperatures Kit: And there was, there is obviously
stuff that we didn't show you. We did start measuring the total amount of clock
ticks it took to do maybe 10 RSA encryption. And then we did start doing
very specific timing attacks. But obviously it's much easier to just do
10000 of them and hope that one faults. Herald: All right. Seems there are no
further questions. Thank you very much for your talk. For your research and for
answering all the questions. *Applause*
Kit: Thank you. Daniel: Thank you.
*postroll music*
subtitles created by c3subtitles.de in the year 20??. Join, and help us!