Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/512 Thanks!
The recent book is always
funny because we're going to present to
you a look of the bus to
catch a tux and Ruhama,
so a few words about ourselves.
So I just finished my
pitch to you a couple of months ago.
And I'm from in France.
I'm from Germany originally, but I live
in Austria for several years.
And I started my PhD
one year ago and I
worked on Catch a Texan this year and
also on Rosmer when I just found that all
my laptops were very vulnerable
to Rosemary.
Yeah, so a few words about
the timeline. So this is a story about
Philipson in dirham.
So it all started basically last
year with schemozzle paper, which
is called flipping bits in memory without
executing them at the
conference.
So this is the original Ruhama book.
With this first inspection, it
will make sense later.
And it was originally viewed as a
reliability issue and the
security community
started to say it might not
be such a good idea to flip it
without accessing then in a security
perspective.
But some people were like, it's just
a few bit flips and we can't really
control them. So what could possibly
go wrong?
So yeah, actually a
lot can go wrong, as I've
shown, massive on and off like
you, who built not one but
two exploits using Ruhama
with flaws. So they built a sandbox
sandbox escape and a
route explodes.
So shortly after that.
So Daniel started working on Ruhama
results still flush.
And I told him to
you got to work on it.
And we got our first bit, Flip's
results on Ivy Bridge and has
well, a few days later and
this story about will self-assertion
results. So the results here
first, as are actually the
building block of our
first pit flips from script that
we got a few weeks later.
OK, so you will see what this is, this is
a direct module at the module and
let's see how it is organized
internally. So, for example,
if you have two modules, you can
have two channels.
It is composed of a backside
in the front sides, which are called
ranks.
And on this Franck's, you have
a chipps.
So inside this ships, you have
eight banks which are composed of
rows and Naropa.
So this is a logical view.
We are not really interested of of
it or of how it's actually
implemented.
So we have our data,
the bits in the cells in these rows,
and we can access only
Ross Perot.
So when you want to access some data, you
will the activists
will issue an activist comment on the
role, which will copy the data into the
Rowbotham.
And due to how the dirham is
designed, the cells are leaking.
So we have to refresh
to to put the shark back so
that we won't have any data loss.
And this is actually leaking faster
upon proximate accesses, which
leads to the Rahmberg.
So there's Mosaab
advice who says something which I
really like an analogy.
So Ruhama is like breaking into
an apartment by repeatedly slamming
neighbors door until the vibration
open the door you were after.
So let's see
how it works.
So you will issue an activist
comment on the special role that will
copy into the Rowbotham.
And you want to issue a lot of activist
comments as fast as possible on this
role. The issue is that if you just
access this role,
it will just you will just go to the
ROBERVAL, which acts like
a cash. So you need to activate
another rule and then destroy
again another rule
and then you have your bed flips.
So this is really bad because we didn't
touch this role at all and the
be changed.
Now, the thing is,
we can't just access data
in dirham just like that, because
between the civil court and the dirham,
you have to keep Yogesh.
So if you just access data all
over and all over again, it will reach
not the Deran, but the cache.
And you won't have this blip.
So you need only non-cash
accesses to reach that.
Iran and all the original text
used this selfless instruction.
So this instruction actually flushes
a line from the cash so that
next access will be sealed from
the.
Now, a bit of background on this cash,
because it's really important for the
remainder of the talk.
So now in modern processors, we have
several calls. So let's say four calls
and we have a really a hierarchy of
different levels of cash.
So here are three levels, level
one and level two private, which call
which means that calls you can access
on each level one and two,
but not one individual.
For example, call three.
And then we have this Lesterville cash,
which is also divided into sort of
slices.
But these slices are shared across
so called zero can access
zero, but also slice one, two and three.
And something that is also important in
that this cash has the
property of being inclusive,
which means that all the data that is
in level one and level two is also
contained in this Castroville Cash.
OK, let's now look at
the Roy Hammer attack with the
instruction.
Now we have additionally to
the dirham bank that we already had
before, two cash sets.
And there is a fixed mapping between
dirham sales and
physical addresses and thereby
cash sets.
So if we already have the
data in the cash, we first have to call
the flush instructions to throw it out of
the cash. Then it's gone.
Then we reloaded
and then we reload the other address.
Then we flush it again.
Then we reload, then flush, then reload
and flush, then reload and flush them.
Slip.
Great.
OK, and before I continue with Rosemere,
I want to talk
about just one more ATEC.
I talked about flash and reloader just a
few seconds ago, right.
Flash and reload is a very powerful
and very accurate cache of tech.
And you can do a lot of things
with this is tech and it works exactly
like what we just did.
But instead of just hammering all
the time, we measure whether
a excess was served
from the cache. So it is a cache hit or
it was a cache miss and was served from
the year. And apparently this takes
a different time.
And if you do this on a shared library,
you can spy on other processes
because these chat libraries, they might
have a method to
go to work
the user with the user input.
And you can see when the code
from this chat library is loaded into the
cache and you didn't loaded into the
cache. So someone else did it.
OK, that was user input.
And you can furthermore automate these
attacks. So when you can simulate the
event that you want to spy on, you can
automate the attack fully and
also generate attacks on cryptographic
algorithms to generate key loggers or
part of the killers.
And you can even perform cross animatics.
If these VMS share memory, it's not
a good idea to share a memory.
OK.
OK, so what we would
like to do is to do this,
this attack, this attack, but without
the salesperson's friction, the global
idea that we would like to avoid the SEAL
section because it's really dependent.
So it's a specific infection in
the six and you won't have it
in the architecture.
And it's also not available
from JavaScript. So it will
really extend the world of possibilities
to do to do this with flush.
So our approach is to use
regular memory accesses to
evict the cache.
And the nice thing about this is
evicting the cache is really at the core
of all cache attacks and this
is really what we know how to do best.
So let's use it
so it works kind
of the same. So we still have this
gray line
that we want to evict.
And now what we're going to do is that
we're going to access lots
of addresses that will map to the same
cash that until eventually
it will evict the line we want.
Now, something that is important here is
that while we can choose in
which case captured the exercise
go, we cannot choose where in the
cash sits, the excesses go.
It depends on the replacement policies.
So we just wait until
we have a victim and
then the next and the next access will be
saved from the tyranny, which is exactly
what we wanted.
Then we have to do that over and over
again until we have
our bit flip without this selfless
insurrection.
Now, it looks
nice and easy like this, but there are
actually some challenges.
First, how do we get these physical
addresses in JavaScript?
It's a sandbox.
Second, which physical addresses
do we need to access?
In which order do we need to access them?
And then finally, how do we get this
accurate timings in JavaScript?
So clearly, they are not that
simple. It's not a trivial task.
OK, let's talk about the first problem,
physical addresses and theorem.
So there is a fixed map from physical
addresses to to different cells,
but unfortunately it's not documented.
Buy into it for several reasons.
Mark Seabourne reverse engineered the
mapping function for Sandbridge earlier
this year. And we continue this reverse
engineering just recently for Sandbridge,
IVI, British, Haswa, Skylake and
in different configurations.
What you might have noticed,
the robot serves
as a cache and
accessing something that is served from
the current rollbar takes a different
time than from a from another row.
And if you have a real conflict that
takes much more time
and you can exploit this to build another
tech.
But let's stay with the physical
addresses for now.
And we now know that
we now know the mapping from
physical addresses to dirham cells, but
we don't know the mapping from physical
addresses from from JavaScript
indices to physical addresses.
Right.
So the operating system always
want to optimize wants to optimize
everything. And one optimization is to
use two megabyte pages and two megabyte
pages are more efficient
because you need fewer Tilba entries
and therefore you can have more entries
in the TILBA to translate
visual addresses.
And if you use two megabyte pages,
you see
that the last twenty one bits.
So that's a two megabytes
of the physical address and the virtual
address. They are identical
and now the mellark implementations say,
OK, it's a good idea to
use it to, to allocate large
chunks of memory.
And the operating system says, OK, it's a
good idea to use two megabyte pages
there. And then we have the last twenty
one bits of the physical address in
JavaScript, and that's
probably a good idea.
So furthermore, what we get
from this.
Is that we have several
dirham roles per two megabyte page,
so we know we have several roles
that we can just now hammer and we
have several concurrent addresses in the
cash. So that addresses that map to the
same cash set. So we can also perform
eviction here.
And if we do not have enough
concurrent addresses, we can still use
timing, information, timing, attacks for
cross page information and connect
these two megabyte pages.
By that, you can also perform timing
and text to completely
work without two megabyte pages
and with four kilobyte pages set.
But that takes a lot more time.
So the next question
now, which physical addresses do we
need to access?
So I'm going to.
Well, this is what we call LRU eviction,
because it assumed that the cash uses LRU
replacement policy.
And this is actually exactly what I
showed you before.
We are going to access and addresses from
the same cash set to evict.
And we sip's and this is something
that is also very known in the in the
field of cash ATEX.
And so it is called primaries and
is documented in this article
if you want to read them.
No, we have this property
of the Lesterville cash that it's
inclusive.
And what it means is that if we
evict a line from the Lesterville cash,
it will be evicted from the whole hinoki
to just guarantee this inclusive
property. So we just need to
evict line from the last of it.
Cash. That sounds easy, right?
Actually, not that much.
Again, so we need to
know very precisely where
the addresses are mapped in the cash.
And for that, for the last about cash, we
need to know first in which slice
and address is going to be mapped.
And there is an internal
process also hash function that
maps physical addresses into
sleights and is and documented by
Intel.
So fortunately, just right
before arriving in, that's
what was what was I was tackling
was a reverse engineered this
dysfunction. And I actually succeeded
in reversing it.
And I was actually not alone.
There were also other teams
working on it. So if you want to release
the gory details on how we did this
and what we achieved, you can also
look at this paper's now fun fact.
This hash function is basically an XO
of attributes.
And yes, they call it a hash function.
OK, so
for the replacement policy we just heard,
LRU eviction is justice and exercise
to address that map to the same Cash
said. And we will just revisit this
shortly.
So the LRU replacement
policy says the oldest entry is replaced
first. So we need to have some kind of
time stamp for every cache line.
And now when we access any
address, it is maybe loaded into the
cache or maybe it is already there and
the time stamp is updated.
And if we do this end times for an end,
we catch set.
Then we have certainly evicted
the targeted address
now on more recent CPU's.
That's not true anymore.
They don't have LRU replacement policy
and that's not good because if you try
LRU eviction and such and such
a c.p.u, it might look like this.
So, yeah, it's just something
you can understand a little bit more.
But but that's too much for this talk.
What I can say, we only
have a 75 percent
success rate on
Hatswell if we perform LRU
eviction and we of
course, we can perform more excess more
than the cash is,
then the size of the cash said.
But this would be to slow.
The success rate will be higher.
So it would work for cash tax, but it
would not work for Rose-Marie.
Instead, we have to think about how to
trick the cash into
evicting the targeted
address earlier. So tricking the cash
in, falling back to LRU eviction.
And one strategy to do that is
this pattern.
So you can see first we exis address
one, then we address two, then we
address one again, then two.
And then two and three and two and three
and so on.
And using this excess pattern, we
have a fast and effective eviction has
with CPU's and also an Ivy bridge.
And it also works similarly on Skylake.
And with this eviction strategy, we can
achieve an eviction rate of more than
ninety nine point nine seven percent.
And this is enough for tremoring.
So there's one remaining question
how to get accurate timing and
JavaScript, and we need the accurate
timing for two purposes.
First, to interconnect these page
informations if we
do not have enough concurrent addresses
on a single page.
And secondly, we have
to decide whether an address is
cached. At some point, we have to decide
whether eviction was successful or
it was not successful and a native
code. This is fairly easy because
you can just use our DTIC and you get
a sub nanosecond accurate timestamp
in JavaScript.
It's a bit more complicated, but window
performance now is just perfect.
It works if you have
enough accesses.
Then there was a recent patch to prevent
casual text in JavaScript.
You should also check out this paper.
It's really cool so they can track
mouse movements and stuff like that in
JavaScript.
And they patched this by rounding
the time to five microseconds.
And this helps against some cache
attacks. But it does not help against
cohering because we perform like millions
of accesses and that we consume
more than five microseconds in time.
We evaluated the
bit flip rate on our Hasselblad
test machine, and we
during this evaluation, we
varied the refresh interval in
the BIOS. So the default
is very low and the 75
something is maximum
refresh interval.
We could set and what you can see
is that there is some point where
the bits slip a bit, flips start
to occur, and for SEAL Flush
and for native code eviction, it's
approximately the same.
We have a bit less bit flips
in the eviction variant
than in the variant.
And in the JavaScript variant
it takes a bit higher refresh
interval because JavaScript is apparently
a bit slower than our optimized
native code.
So this is a number of lives within five,
15 minutes, you can see that in the case
of eviction or see of
the flush and even for the higher refresh
intervals for JavaScript,
we have like more than 10000
bed flips. That's more than 10 bit flips
per second.
OK,
depending on your machine, it will work
that well or it will not work that well.
That's totally up to the hardware
that's in your system.
So let's now talk about exploits.
How can we build exploits from this from
these boot flips?
And the first idea we had?
Yeah, we just part the root exploit
by Mark Seabourne to JavaScript.
And actually this might work.
We haven't finished this work yet, but it
might work. And the exploit
by Mike Seabourne works by doing Page
Tabit Spring. So you fill the whole
memory with page Tabors.
And if you have a bit flip in a page
table, that's bad because you can
gain access to one of your own page
statements by that.
So this exploit needs shared
memory because you map all the time on
the same page again.
So you don't need any physical memory for
your page, but only for the page tables.
And we don't have
short memory in JavaScript.
But fortunately, we observed earlier
this year in the when working on another
paper that zero
pages are usually hated.
And this means we have some kind of
shared memory because all zero pages will
map to the same physical page.
And then we have some kind of shared
memory in JavaScript.
That's bad.
OK, physical
memory access in
native code, if we want to build the
exploit, we just follow
a few steps. The first is find and
exploit a little bit flip.
So a bit flip that in the right position
and address it probably.
And then we release the
page where we have the bit flip
and then we try to put a page table there
by doing the page table spraying,
allocating a lot of pages,
and then we try to trigger the bit flip
again and then we just check whether
it was successful, whether we have a page
table now mapped instead of the Shell
page, and then we can try to modify
the page table and see where
in our address base something is
changed by that.
Now, if you want to do the same exploit
in JavaScript, we would
use zero pages and zero pages are
read only.
So we have to only to change two pieces
here. And this is attack.
The first is we also have to flip
flip the right of it.
And that's much harder because the writer
is in a specific position and
we only have one right a little bit and
not many bits.
And the
other thing we change.
Yeah, we use zero pages instead of the
shared pages.
I tried this on my machines, and it is
possible to find such big flips,
but they are, of course, much rarer
than other big flips, regular flips,
single bit flips.
OK, code
execution as a route, if we want to have
that from our full memory access,
that's also, again, rather easy
because we can just search for a known
binary page and modify the
page and add some special code.
And this page will probably not
thrown out of the memory because
we have a large file cache in our
operating systems and then we can just
wait until the root
user executes the shell code and
do anything on the system.
OK.
Now we have a nice attack, we have to
find countermeasures against it.
Yeah, so the
first thing that comes to mind is that we
should avoid the bird I
right at the beginning. So it's a
hardware issue.
We should patch it in hardware.
And actually the Windows are currently
doing this.
So one solution is to do some
sort of dynamic or refreshing.
So the idea is to refresh the
rows before a bit flips can before
it flips can occur.
So sort of a smart way
of of refreshing drops
knows. The issue is that it can only ship
in new hardware.
You cannot patch your own hardware right
now. So we have sort of huge
issue of legacy hardware because
the Ruhama bug, it
basically affects all
different vendors.
So it's really widespread.
And we have this hardware that will stay
for a few years.
The second idea is to patch the bios
again. It is already shipped
here. That is more simple as a sort of
dumb way of doing this.
We just increase the refresh rate.
We refresh all rose
more often, usually by doubling the
refresh. Right now, the first issue
is it it might not be sufficient for
all machines, as was suggested
by the original paper.
Now, the second issue is a bit more
pressing is that we need the
BIOS updates and like who
does that?
Seriously?
OK, we had another
idea, because we want to make
we want to find something against the
problem, and one idea that we had was
while we were hammering all the time and
had no bit flip that was exploited, we
thought, OK, life
is not perfect. That's OK.
What if we just say we don't care about
these self-destructive processes that
have been flips in their own memory?
We just have to prevent that.
They have bit Flip's in memory that
has a different privilege or a memory of
other processes. We just have to prevent
this. And if we can prevent this,
then we can prevent any Rosmer exploits.
And that's OK. Let's say rumoring
is OK as long as you cannot exploit it.
So the idea is
to have sort of physical memory pools
in physical memory.
You separate pages that have different
privileges and have gaps
in physical memory that prevent
that any bit flips occur in different
privileged memory regions.
Now, that sounds a bit awful, but
if you think about it a bit, it could
work if you if your group is into
privileges and you only only have to
leave a small gap between these memory
pools.
So for the conclusions of
cash, eviction is fast enough to replace
sales that we have seen that and
without still flush, our take is
independent of programing languages and
available instructions.
So we could even perform it on
our smartphones or something like that.
It's the first hot refold attack in
JavaScript. It's also the first half of
tech in that is performed through
a remote website.
And performing this attack through
website and through a website is actually
a bit awful because if you say,
OK, Rosemere, maybe one percent
of systems is affected.
Yeah, if I run a website and run this on
one million users, that will still be an
awful lot of people that are affected.
Right. So we are not there yet.
But look out for the Roma Jass
JavaScript framework.
Thank you.
Thank you very much.
We have about five minutes left for
questions and the first two questions
over the Internet.
Hi, Daniel.
So pretty much all of
our U.S. wants to know, what about
Ekrem, how is Iran vulnerable?
Yeah, that's a great question.
Thank you for asking.
It is a serum basically
works like this. You have these eight
chips and you have a nine chip there.
And this ninth ship also has rules.
And if you zero here, it has to get to
check them from here.
And then you access this through here and
then you access Israel here for the
checks. Right. So you hammering both
sides at the same time.
What then happens is I'm sure
there are there is a serum that is more
resistant to Rosemary hammering, but that
is apparently the serum that is
less stable against
Rosemary. And that's disturbing, right?
And the second question for me is that
Frank wants to know, does it work
the other way around like no chance
working on the server and attacking the
server through input and
the Web page?
I didn't get it.
Also notes is
China. Yeah.
What would you do with Noticia, exploit
the server? Oh, yeah, yeah, probably
that would work.
If you can execute JavaScript code
on the server, you could do the same.
So on server side, yeah.
OK, the gentleman with microphone one,
hello.
So the easy question
would have been my first question, so
could I have a second one?
The second question is, is
a shot nine a shot enough
refresh rate?
Will this always prevent
Rosamma or is this not
enough?
As a fix on my
laptop? I just have here
the I observed one
bit flip where I had to perform.
Sixty five thousand
of these double hammering
accesses 65000
accesses studier.
That's only a very short
amount of time.
I don't think you can solve this with the
refresh rate, but for most laptop
it will most laptops and desktop
PCs, it will be sufficient.
So here the answer was the
range you can manipulate in
the BIOS. My question was, oh yeah, you
range of existing biosequestration
walls.
If we will always be able
to produce a bios with type of timing,
which is enough to prevent Roraima
not you cannot configure configure
it in all bias's, but if you can
configure it you can set it.
Certainly set it low enough that you are
resistant against Rosmer.
OK, next. Next question, microphone two
and also that microphone number for you.
So you just mentioned mobile devices,
have you ever tried it, actually?
And how much mobile devices
are affected?
Yes, we tried it and we even
put a smartphone for that in the
refrigerator because that apparently
changes the refresh interval.
But we.
To have the bit flip's, you have to
hammer the Turow's, right, and
right now we have not yet
reverse engineered the mapping
for the EP three
on my smartphone, so
we still have to do that.
OK.
If I understood correctly,
the hammering is more
effective in flipping beats,
the faster it occurs.
So did SMK
support in paralysis make the attack
more effective?
To my knowledge, as MGE
does not provide you with native
access to native code, it just provides
you with efficient
ways to implement something in JavaScript
and you can basically
do this by hand.
This takes like X or zero to something
and then it will be a more efficient
statement in the optimized code
that is executed on the CPU.
And we sort of
did something like that to
to run our attack in JavaScript.
But it's really simple to to achieve
this. You don't have to perform a lot of
optimizations there because it's it's
pointedly referencing what can you do
wrong with it.
OK, thank you.
Time is up. Thanks for the excellent
timekeeping.