36C3 - Plundervolt: Flipping Bits from Software without Rowhammer

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!