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/743 Thanks!
Memory deduplication is widely
applied to reduce memory consumption.
Today, we are going to see three
attack techniques that exploit
memory duplication.
We have two incredible
security researchers here with us today
that will show us how this attack works.
And to the left, I have
Antônio about. I see.
And to my right is Eric.
Busman, busman, sorry.
And they will then use the chance
to also introduce themselves.
Please help me welcome Antonio
and Eric.
So good morning, everyone.
This is Meredith application, a curse
that keeps on giving, so unfortunately,
it's just Eric and me.
So Ben and Kavi couldn't make it,
but they say hi. And I just want to say
that the credit goes also to them.
So be prepared to talk together
and a big part of the comfort comes from
them.
So, Eric, as
he was introduced, he is a Ph.D.
student at the Food SEC
Networks and Systems Security Research
Group in Amsterdam.
So if you want to see what they do, go to
the website USEC Dot Net.
And I'm Antonio.
I'm co-founder of Xolair
Swiss I.T. Security Company
in Zurich.
So the work that we are going to present,
actually, there were a lot of other
people working on that.
And here are some acknowledgments.
And yeah, so let's start.
So the message today is actually quite
simple and straightforward
memory. The application is much more
dangerous that you might possibly think
in the beginning.
So it comes along like a nice little
feature that helps you save memory.
But we're going to show you that it's
actually dangerous and much more severe.
And we're going to do that by showing you
three attack techniques that all exploit
memory lead application, one or another
way.
Before we do that, we'll look at memory
applications so everyone knows what it
is.
We're going to show you the side channel
that gets introduced by it.
And then we start with the three attacks,
so first we have Cain.
Cain is across the leak attack,
which basically allows you to leak based
addresses or other secrets
with higher entropy from other
VMS. And we applied it to ASALA because
we thought it's an interesting case
and it only relies on memory.
The application will
then show you up as maquina.
This is an attack against the process
and actually got the Tony Award at
this year's Blacket for Most Innovative
Research, and it relies on memory,
the application and Rosamma.
And basically it allows you to read and
write through JavaScript in
EDG.
Without any sort of vulnerability.
And then we're going to present Philip
Feng Shui, Philip Feng Shui
is crossbeam a
bit flip atec.
So basically imagine you could
flip a bit in another VM
and the only requirement is
you have to know the content of the page
of any page.
So how will you actually compromise that
system? So we're going to show you.
So first of all, how you can flip
precisely.
And then we are going to show you two
techniques to actually compromise the
system with that.
After that, we will conclude.
So let's start with marmorated
application so that when this application
is a method to reduce memory consumption,
then it's usually used in ritualize
environment, but not exclusively.
And it was also enabled and the emphasis
is on was in Windows
eight point one and 10.
So the idea is that in relativize
environments, for example,
the virtual machine module will try to be
quite a resource
and or try to save
memory. So basically overcommit
certain resources like memory and very
little application is a technique to
reclaim certain pages in a
clever way or
the easily speaking run
more VMS.
So basically, it's a nice feature, right?
The idea is you can you
can just have more VMS on the same
hardware, but you'll see that it has
certain implications.
So let's look at how it looks.
It works. So basically, there's an
example. You see memory pages of two
virtual machines and the physical memory
of the hardware.
So let's say you have like
the picture of the Mona Lisa or a same
process running through the same court
pages or something else,
some data.
So basically, in a normal scenario,
you'll have both addressed spaces
filled up with these pages and all
consume one physical page.
So when memory the application is
enabled, the memory
application implementation will try to
identify these duplicates
and then it will merge them so that the
global space gets free again.
And it will mark these pages with
a copy on the right semantics, which
basically means if someone writes to it,
it has to do something else.
It's not going to work.
Now, one implementation is Colonel
same page merging with Kadian.
I'm sure most of you know that.
So if you have a one to several
want a system, usually that's I think
even now enabled by default
and you can check it. So there is like
the wrong file under the cease fire
system where you see if there is a one
there, it's enabled and then there are
certain parameters that allow you to
define how fast a memory application
should work.
And there are other implementation as
well.
So the problem with the application
of most implementations is that it
doesn't respect the security domain.
And so basically, even
between two different VMS or if it's
done for processes, if you have two
different clauses, you can not trust each
other. But it still works
across these boundaries.
And actually, that's the dilemma
of this application, because
in the end, you want to save memory.
And it makes a lot of sense, right?
If you have a lot of VMS running the same
operating system.
So it makes sense to cross these
boundaries. But the problem is it
introduces a side channel.
So let's look at the side channel.
So if you have a page that belongs
to you, you'll just write it and that's
it. OK,
so the problem is if you have memory
application, you have copy, right?
So now if you're right to it,
you need to go to the kernel.
The page has to be duplicated again,
TESTOPEL page tables and then resume
the process again. And then you basically
can write to that page.
So you see that there are a lot of more
steps involved here.
And this introduces a one bit side
channel that allows you to see
basically if such a page exists in
another process or in another.
VM
works across VM if it's implemented in
the virtual machine monitor, across
process, or as we will see,
we will see one instance of that attack.
Even within the process, we have
different security boundaries.
Think about your JavaScript code, right?
So it might be interesting for you,
JavaScript code in a browser to find
out certain things.
So let's look at the Techwood perspective
now. So what does an attacker have to do
to exploit that?
So basically here the attacker has his
memory. This might be a verb or a
process, and then there is the victim.
So there is a secret page that
basically knowing that that page exists
might help the attacker in one or another
way.
So what the attacker has to do is the
text has to get a page.
So in that case, he really has to guess
the content of that page
attacker has to wait a certain amount
of time, write tweets
or modify his copy of the page.
So this is totally legitimate.
You don't need more privileges, right?
Measure at a time and then see if the
right time is above a certain threshold.
The attacker can deduce that
that page existed in the
other VM, for example.
And if the right time is below a certain
threshold, the attacker can then
use that didn't exist there.
OK, so let's look
at the first attack.
So Cain is crossbeam address, basically
introspection.
I actually regret already the long name
and we don't have to see and basically
only relies on
the idea is to use that to
break Áslaug.
So basically you have a VM that runs
next to you memory.
The application is enabled and you will
be able to find out what the base
address, for example, of NTD is in
the other VM.
So let's recap what you have to do as an
attacker. So first, you need a secret
page that allows you to deduce
interesting information and in our case
is to SSL, our base address of a certain
Dellal, for example.
So the question here is what
page will we use
then? Of course, there are certain
practical challenges.
So how long should you actually wait
for? Because you have no idea how fast a
memory application scheme is.
And then in the end, you have to
practically detect that it was merged.
So you can measure right time.
But you'll see that in practice there is
also noise involved.
So sometimes the right time is higher and
it's not because of memory need
application.
So we looked at sortable
pages to break ASALA and
I mean certain straightforward,
critical areas are, you have to know,
always an attacker that the page exists
in a lot of VM.
It has to be read only ideally in the VM
because if it changes too often, then it
will not be obligated and
it has to be page aligned.
So you really need to know the content
mostly of that page.
And then if you want to break ASALA, you
need ideally a page that has a
base address in there.
So basically the green part is totally
predictable for an attacker.
And the only thing that the attacker
doesn't know is the base address
or another possible
page will be a page that actually has
different values that were derived
from a base of those from the secret that
you're interested in.
And the other thing you have to know is
also the offsets of
these secrets within the page.
So we were looking for certain pages and
we are sure there are much more.
But luckily, when we were looking at the
first page of every executable
P image in memory,
you'll already have a hit.
So if you look at the file format,
it looks like on the left for.
An image on this, so there is an image
based field there which basically
gets updated with the runtime based
address in memory,
and this is exactly what we need.
We can predict in all other bytes
except for the base address, which has
19 bits of entropy.
And there are, of course, other pages
that fulfill that criteria.
But we thought, I mean, why
should we look for if you already have
have one?
So we use that page in the pocket.
So another problem is you have this page.
You can basically ask that memory did
application such if if that
exists or not.
But the problem is you still have to
guess the base address.
So you have 19 bits of entropy.
So 90 bits of entropy
in its 64
windows is used for the base
address of the yellow, for example.
So as you need one page
per guess, it's more than five hundred
thousand pages that you will need.
Right. So if you will do that after each
other, basically will take a lot of time.
Of course, we can just brute force
it right so we can use much
more memory, all the memory that the
attacker actually has.
Right.
So the target is much more memory.
Can assume that usually you have maybe if
you have a different VM two, four or even
more gigabytes, so
we can just fill up the entire memory
that is at our disposal with all
the guesses.
And in case of 19 bits of entropy
and one page per guess, it's two
gigabytes, which actually is
OK.
So what you do is you have these pages
and then you allocate them
and then you try to detect it.
And it's a classical brute
force attack on this that memory need
application like.
So the other challenge that we had, the
practical one is how long should we wait?
Of course, we could just wait like hours,
right? And at some point it would work,
but it depends. So we wanted to be a bit
better. So in the end, it depends on the
application implementation.
So how fast is it?
So you've seen the parameters
for KSM, so depending on the parameters,
it might be faster or
slower, but it also depends on the
memory usage.
So if you have a lot of VMS running
in the end, you have to compare all the
pages to each other.
So you have to go through all the pages.
And if you assume the worst case, then
your guess page will be compared with the
secret page at the latest point
in time.
So there is a trade off for the attacker.
So if the attacker waits too little, then
the attack will just not work.
But if the attacker waits too long, then
the attack increases.
And that's also not favorable for the
attacker.
So what we came up with is a detection
mechanism to detect these marmorated
application.
Basically the time you'll have to wait
till you have certain guarantees that
your page was compared with another one.
We call it sleep time detection.
And the idea is
as an attacker, you can just allocate a
lot of random bites and a lot of pages
and then you copy every second page
of the half of your buffer to
the other half of the buffer.
So what you create is basically the
situation like on the slide where
you have a lot of emerging opportunities.
So you basically give the memory, the
application scheme a lot of work.
You create a lot of pages that can be
appreciated, and then you wait a certain
amount of time, like 10 minutes,
to try to detect how many of these pages
were merged by doing your detection
magic.
And then if the threshold is a detection
of a certain threshold, you say that's
the right time.
So you use it when you were attacks
and if not, you just increased and then
you try again.
So last practical challenge is
how do you actually detect that the page
was merged and what you have to do is I
mean, you have to write to it and you
have to measure the right hand, right.
So what we did is we every time you have
a guest page, so that's the orange one,
the merged one, we have
pages, adjacent pages that are
for sure not merge.
And we know that because we can just fill
it up with random bytes.
OK, so you create
the buffer in such a way and
then you just write to it and you measure
the cycles and then you basically
see this signal.
Now, of course, there might be noise.
So we developed certain juristic.
We didn't invest that much time to do
that. But the ones you see there worked
pretty well.
And that was fine for us.
Works for me.
So now the last
question is how to handle noise, right?
So we just implemented it in a
quite conservative way because there is
actually no harm if you
have certain pages
that certain false positives.
So what we did is we implemented rules
based system where you try to detect
it. Then you do it again with the guesses
that might be potentially correct
and you do it over and over again.
And in the end, as the noise
will not affect the same guess
all the time, it will work,
but it might take certain rewards.
So I'll show you some results for
Windows attacks or we implemented it to
attack, to basically leak
the anti the address of a neighboring
Windows 64 bit system.
So if you look at the entropy, you see
basically for data, it's quite high.
So that approach wouldn't work that
easily,
at least not if you have no control
over how this the secret is is
aligned.
So basically for us, we have 19 bits of
entropy. And if you have the basic rights
of one entity, you basically can
use it in your exploits for all the other
processes because it's usually not
re randomized.
So we did it with a standard KVM,
some configuration with sleeplessly sex
to that's default.
And basically, you see when we attack one
single B.M., it took us a bit less than
five hours to basically
do that. And we had like some rounds
until we reduced entropy from 19
bits to to the actual base
address.
And we also wanted to show that it works
with multiple V, so we speeded up
the memory application by having sleep
merely six 20.
And there you see, even if you have more
victim VMS, it works.
It just takes more time because the sleep
time detection will tell you to wait more
because you have more memory that is
used.
So in the end, it looks like we have a
woman, but we don't have that much time,
so just show you the screenshot.
We have a demo for for another attack
later.
Basically, here you have the attacker,
B.M. and on the right, you have the
victim and you do
your magic. Do you allocate
these pages right times and so
on. And in the end, you just have
the base address of of the entity
in the other VM.
That's it.
So the attack is rather
slow, I will say, but there were a lot of
speed improvements that we didn't
actually follow up with, but
one way would be to have more random
pages in between so that
the noise will not affect your guess
or the probability is lower.
That happens.
And the other thing is you can also use
more than one gasp.
Try to have redundancy already
because you might have for example, we
located code pages that all have that
secret. So we can just use many of them.
Right. The only thing is you cannot use
the same page because if you have it two
times with the same gas, then you create
this emerging opportunity and you have a
false positive. So we need different
pages that all have the same
uncertainty or the same secret.
Now, I will say cool
tech, but the problem is it's still quite
limited.
So one problem is we don't have any
control over the victim memory.
Right. So we really have to rely on
how these pages are, what
the layout of these pages are, and
also where the secret actually is.
And we need to find these pages so there
is no control, but some control would
actually help a lot.
So we didn't really investigate that.
How we can do that, Crosslin.
And then, of course, it's a league,
right? So you still need a vulnerability
to exploit the base of risk.
For example, a secret.
I forgot if that's not enough.
But last year, I mean, there was
a lot of a lot of talks
and a lot of publications about
Warhammer.
Even here at the Congress,
Clementine and Daniel presented
all. So basically to show that it's
possible in JavaScript.
So let's say
we are we were optimistic that
we could do more.
And then Microsoft basically enabled
marmorated application, what we noticed
for Windows eight point one and 10
across process,
but disabled again.
So it's not enabled anymore,
but let's say would have been cool, but
it didn't go that well.
So for the next attack, we call that
Makina, we tried to take it a step
further.
Um, so in this attack,
we're going to
combine the occasion as
such an attack with a hammer
in order to exploit a
Microsoft Edge new
browser from JavaScript
without making use of any software books.
Or, well, if you consider
if you don't consider deduplication a
software book.
And
so we're going to link to secrets
and we're going to use the occasion to do
this.
The first secret is
a hip, a hip pointer.
It's a location to data we control.
And the second secret is a code pointer,
and that's needed.
And those two secrets are needed.
The two together
create a fake object
in our memory.
But then we have a problem because
this fake object will allow us to do
arbitrary rietz and arbitrary rights in
memory.
But we have a problem.
JavaScript, of course, doesn't allow us
to create references to this
fake object. It's just in data.
So we will use Rosmer to flip a
bit in a pointer and point
this pointer to
our fake object. And then we are
basically we can take over the process.
So in this in contrast to
can in this attack, we
won't only be using be
probing for existing pages of memory.
We will assume that we can
manipulate the data of
the the victim
in some way.
And this is not really unlikely.
If you think about it every time you do
IO to something you
want to attack, then your
manipulating memory in
this process and in this case is
from JavaScript. So
it's even more easier.
And this allows us to not only probe
from for secrets that just happened to be
in pages that we can leak,
but we can craft
memory pages that just contain the
sequence that we want to like.
So there's quite a bit more powerful.
But still there are some problems with
this.
Uh, the secret that we want to link
might not be
somewhere.
Uh, the secret we want to
is probably somewhere in the page,
which contains other information that we
don't know. And then we cannot craft
a page to leak the secret.
So we need to find a way to
kind of encode the secrets into
a memory page
so that we can
retrieve the secrets again.
So, uh, so so the
secrets, the memory patients we want
to leak should contain only
the secret and data known to us.
Um, so this
could be that, uh, because
this data was written
by us into the space of the victim
or it's just data that we know.
Uh.
Yeah, but that we know
the contents of in some way
and there's a second problem, we
might want to leak a secret which has
too much entropy, so much entropy
that we cannot possibly
brute force the whole
all the possible secrets.
Uh, and for this, we have found
some ways to get around this and
leak secrets iteratively.
Um, the first
method we, uh,
we tried was we call
alignment probing in this, uh,
this case, we
manipulate the victim
into creating a memory patch
or putting the secret somewhere
across memory page boundaries.
In this way, we can.
Uh, in this way, we can
only we can partially
leaked the secrets in one.
In one round
and then when we
done that,
we have to get the victim to
create a memory page with the sequence,
slightly, slightly more of the secret in
one page and so
on and so on until we link
the whole sequence.
The second primitive, we
tried what we call partial
reuse, where we assume that
the the victim
has a secret somewhere.
And then we write data,
for example, in a buffer that
was previously used to store the secret.
And then we write in this buffer
and overwrite only part of the sequence.
And then again, the entropy,
again, such as entropy, is low enough to,
uh, to leak it.
Uh, and the first
of these to
allow probing is
what we are going to use to leak the code
address in this case.
Um, and we're going to make
use of, uh, uh,
just git's, uh,
compiler. So every modern browser has a
compiler compiling
JavaScript to native
code. And, uh, for
every chunk that's translated in
edge, um, the
the function epilogs at the last
part of the transitive code is oh it
looks the same except for one
thing, namely a code address.
So uh and
what we did was create lots of
uh JavaScript functions which are
just uh
uh just too big to fit
into one memory page such
that the code address
spans multiple pages.
And then, uh,
well normally the code is 19
bits. So it wouldn't we would need two
gigabytes of memory in this case.
We need on the 16,
I believe.
Um,
and so, um,
so so we in this way we can in one
sweep we can lick
like part of the address and then the
second so we can look at the complete
value.
So now we have a code pointer.
Um, but we still need to
point out and there's a problem with
this, uh, we didn't find
a situation where we could link the
pointer directly using the two
primitives before.
And the point out has
quite a lot of entropy.
So this is an example
of a hip pointer in, uh, my
edge.
There are some advertize randomness on
Windows ten, twenty four bits
of randomness.
And if we only look at that part, uh,
we need sixty four gigabytes
of memory just to try it.
Every one, every every possibility.
And then we need to multiply this by
a bit to get redundancy
because there is noise.
Um, but if
we look at uh uh our
point, actually it looks like there's
also some kind of lots of non
determinism which actually
increases the the entropy
of the point by quite a bit.
And yeah, we don't have hundreds of
terabytes of memory to probe,
so we needed to find
something else.
We could improve this a bit.
Um, we found another side
channel. So if you allocate lots of
arrays, then every
one megabyte,
the browser will ask the operating system
for an extra megabyte of memory.
And then the first
object that fits in to the new,
uh, uh, one
megabyte, it
will take longer to allocate.
And that's something you can detect.
So then, um, we have a timing
channel and then we can reduce
entropy to 20 bits,
but we don't already
need at least four gigabytes of memory.
So that's also not
nearly good enough.
Um, so we
have to find something else.
Well, but we found something else,
something, uh, very much
like, uh,
uh, intuition is very much
like that of the birthday problem,
which, uh, uh,
in which you in a very,
um, in a surprisingly
small group of people, the chances
of.
Two people sharing the same birthday
is actually becomes pretty
high,
more than more than you would not usually
think faster than you would
think that Iffley
and the intuition behind this is that
you're not comparing one person's
birthday with a group of other people,
with other people.
You're actually comparing everybody's
birthday with everybody else's birthday.
And when you think about it,
this is exactly what memory, the
memory, the routine
does as well.
It compares every page with every other
page.
So how can we exploit
this in practice?
Well, we're going to assume that we don't
have one secret civic,
but lots of secrets
and then we have lots of guesses.
And then there's a
comparatively guess with every secret.
And then you get, yeah,
we need way less memory.
So
so in practice, this becomes
secrets and then
you kind of need this, you don't
need as many different
guests to actually get the match.
So how do we exploit this in
practice? Well, we have this
we allocate lots of objects and then we
get the due to the other side channel, we
get to
a list of objects which have are
probably on one on the megabyte
boundary.
And then we look
at the large array, which, of course,
is in practice just memory pages,
and then we put a reference to
or a pointer to each object in
this array. So and then
there's one pointer
from memory page.
So these very pages kind of
encode the addresses of
the of the objects
and those pages we're going to
probe for.
And then on the other end.
We're using a type array which allows us
to completely control the binary
contents of memory,
and then we're going to
create references to
objects which are one hundred and twenty
eight megabytes apart.
And then recreate the contents
of the
of the the pages that
the, um,
the contents of the letter.
How that would look like if they were in
the array.
So so
you can see the the secret pages are
close together and one
megabyte the parts and then the
properties range
across the entire address, the possible
other space that
that's that you might possibly use.
And then in the middle there's a hit and
then we get our address
going to a.
Belonging to an object
where we control the data.
So now we have
the all the information to create a fake
object.
Now we're going to use Rosemere to create
a reference to this object to
allow us to use it.
So the object is a type of array,
the fake object that we make, which
allows us to basically control,
read and write the entire airspace.
Um, so this doctora
this this type of object, this
fake object we recreate in.
A JavaScript, right, that we
know the address of
and then.
The next JavaScript array as a pointer
to it, and then we
recreate in such a way that if we flip a
bit, the pointer will
point to our object instead of the
array.
And that's what we're going
to use, the real hammer attack.
Yes, like Antonio
said last year,
some of you might have seen the volume of
just talk.
Um, we were
able to reproduce, uh,
their findings and, uh,
on Windows ten, uh,
and use it to
for it attack.
In the Rome attack, the problem
is that our memory.
Use this capacity, the capacity
to store, uh, memory, uh, store
data, and when you have to when
you read it, the capacitors are drained.
So, um, these
capacitors are stored in rows.
And then because they are drained, there
has to be some kind of cache which
doesn't lose its use, which
is just, uh, static from
a buffer.
But it's only a limited amount of memory,
so when the memory controller
needs to read a different role, the
data has to be written back to these
capacitors and a different role
is read to the
the buffer.
The problem is that this
interference and if you do this in
quick succession
at a specific locations, then,
um,
and, uh,
then after a while, some bits
may flip in neighboring rows.
And that's what
we used to flip a bit in
the pointer, allowing
us to get a reference to
this object and basically
taking control over the process.
So that's the second attack
in the third attack where
we call what you call flip flops, where
we actually are also
using raw hammer in combination with this
operation, but in a different
way. We won't be using deduplication
as a software side channel anymore,
but we will be using it
to make Rahim more
a more useful
exploitation, primitive.
And our target will be,
uh.
One, on our in
our attack, an attacker
will be in control
of one virtual machine and will
take over another, Froch a machine on the
same system.
So like I said, the
hammer is a rohmer's
a very powerful
attack, but it's it's also
quite difficult to exploit because
you can corrupt bits.
But it's not really you don't
really control which physical bits
in memory are vulnerable to it.
And if you can flip
bits you have to
it did the data, that's
the data that's being corrupted
as to be useful to you.
So you have to you
kind of have a problem of getting
the right data into the right location
for you to exploit.
So it's
unpredictable in
which physical page the
flip will happen and it's unpredictable
in which location.
In this page, it
might happen if
we can solve the
first part for you.
So given
that you can flip a bit in some page
on the same, in some location, in the
page function,
I will give you the
ability to get
every page, you know,
the victim has and put it
in the location where you can flip it.
Another thing to mention is that with a
hammer, if you discover
you can flip a bit somewhere, it's
very likely you can flip it again and
again and again and again.
So.
So we're going to.
Look for pages that we
want to in the victim, that we want to
flip and then
make sure that these pages are
put into a location where
we can flip this bits.
So we thought maybe
the depression is a kind of
an attractive way of
doing this.
We thought
and we we're working on the Windows
10 attack and we
thought, well, what if we
if we do Rosmer find a bit
flip?
What if, uh, if we find
a page, that's where we want
to flip a bit.
We just replicate the same contents
of this page and then wait for Windows
to merge them and then hope our our
look at our page would be the
the location it would merge
to.
But sadly enough, on Windows,
Windows allocates a new page and and
points the the the
old location to the new location.
However, we found that on
Linux with a kernel
patch merging, it didn't.
So and it had some
other
it had some other
things that are contagious to us.
For example, Linux
tries to give
a physical memory to, uh,
to a virtual machine host for efficiency
sake.
So which makes it
easier for us to do Rosmer and find bit
flips and also makes it easier
for us to
make sure that this bit flips occur
in our own memory and not in
someone else's memory, which
we wouldn't want to corrupt
a system before we can exploit it.
Of course, uh, crash the system before
we can exploit it.
So.
So once we know we can flip a bit,
that's useful to us.
We replicate the the
contents and then wait for
them to merge
memory. And we can know
in a, uh, in a deterministic way
whether will merge it to
our page and then
we do roll them again and then
we can exploit the
target victim.
So one example how we did this
was by attacking the authorized Keys
file.
Authorized Keys files usually contain
the public keys
and these public keys are
not supposed to, uh,
yeah. They don't have to be kept secret.
I bet lots of you have probably uploaded
there are public key to get up
and they're public.
So.
Yeah.
Um, and what we
see here is in yellow,
we see the.
So this is an RSA public key and
in yellow we see
the RSA modulus, uh,
base64 encoded.
Um, of course
we're not supposed to characterize this
modulus because then we can get the
private key.
But in red here
we have uh uh
uh uh, characters
which contain at least one bit
that one flipped will remain
base64 encoded, but
we're able to factories, uh,
the modulus, um, uh,
within one minute.
So that's
what we did, um, flip
a bit in the, uh,
in the modulus factories
and then reconstruct the private key and
log in and.
We have a second example where
where we target GPG
and get to exploit
the mechanism in Debian
or Ubuntu.
So this is a two
stage attack where we first create
sources that list file to
redirect the updates
repository to a domain
name we control.
Um,
and we
also corrupt a bit in the
keyring to come up with the signing key
to a key that we can reconstruct
and then we can backdoor it,
uh, and
then we can backdoor
packages, uh, being installed.
So we have a demo for this as well
first.
So this attack, uh uh,
so what you see here is, uh,
is a machine running both an our
virtual machine and a victim virtual
machine.
Um, in the
top right corner, there's the
the victim. Well, in a minute,
uh, so top
left, there are some debug information.
Uh, uh,
the bottom part is the the
access log of of a
piece of data repository server
that we control.
And the middle part, uh,
is used to create the
fake, uh,
create the fake package.
So now nothing happened
yet and let's get a
better run.
So this is all fine.
But now we're going to flip
a bit in the source of the list file.
And then when we do
get the update again,
um, there will be an error
because now it will connect
to, uh,
our repository, of
course, uh, at this
step doesn't have to be, uh,
uh, done.
But this just to show that
the that it now connects
to the first to
our repository.
Well, then we have to wait for a while to
find a bit.
That we can exploit to corrupt.
And when we have done this,
we can reconstruct a
private key and
create a new package with the new
assigning, he.
A new package.
And then when the.
When I upgrade this one.
First, we do a less still,
OK, but then after
the update.
Our colleges run, so.
So in conclusion,
I think,
um, yeah,
I hope so, we hope to have convinced
you that memory deterioration can be
dangerous if you're thinking
about, uh, employee, uh,
deploying it, think we'd like
you to think again and think again.
I think again and then maybe conclude,
well, maybe let's
just disable it.
Thank you very much.
So we have time for questions,
if you do have questions, please come
forward to one of those four
microphones.
Does the Internet have a question for.
No, no question right now,
OK, we have a question on the microphone
on my left side and the front,
please, please speak loudly into
the microphone so we can hear you while
people are leaving.
I would like to ask, how does this apply
for large pages?
So I think in all your examples had small
pages, FOID Kilobyte.
So how does this apply to to make op ed
pages, for example?
So Kernell same page
merging employs large
pages, but actually subtly
was good for us.
But certainly
the same page
birching prioritizes
merging over Euge pages.
So actually we create huge pages
at the start and to do the Rosemere
part, that's the creative
memory
thing. But when Colonel S.
Page merging
finds a page
which is identical inside this page,
it will break up the page and merge
anyway.
So that's actually the worst
worst case scenario.
OK. Thank you.
Great. Thank you.
Then the next question would be
right behind you. Yeah.
Thank you.
Yes. About the process of deprecation
itself. Does it use hashish or other
things to actually speed up the comparing
or some sort of exploration, maybe even
or what to stick and the timing
before impact of that
process running on the background.
So we didn't do, uh,
research on on the latency,
but I think it does use some form of
hashing both on the next and when
those.
Yes, and the next question, please,
and well, before you ask a question,
could I please ask the audience to remain
quiet at this point?
Thank you.
So these attacks,
they require that I
am the attacker own
or at least have interactive access
to a virtual machine hosted on
the same
host as the
target machines, right?
Yes. OK, so
what are the implications for a
Siwiec VM or whatever
environment thinking
of desktop virtualization
were? Actually, the virtual
guests are being used
for interactive access.
And so you run JavaScript in
a browser or whatever, because I'm
like every week being approached
by companies trying to sell us desktop
virtualization.
So the idea of running
that gives a complete new
large open door for four
metaverse spreading across
a virtual client computers.
Right, if they have those desktop
virtualization.
So. So, um, our second attack
that as Machina was done
on Windows 10 so that we could
leak information, uh,
because Windows 10 does
Mary deduplication not
only for not for virtual machines, but
also for its own processes.
So, uh, and Windows has disabled it.
But if you run windows
on the hypervisor where the
application is yet again
enabled, then you have the same problem
again.
Thank you and then I have a question here
on the right place.
Do you also have the problem if
you so
are you vulnerable?
If you have both?
It's a C memory and
access to any cryptographic
secrets from
deduplication.
Um, so
I haven't seen a practical attack
with this memory on Rosmer.
I don't know. So, uh.
Um, and
I guess if you if
you have cryptographic secrets and you
don't duplicate it or you put
some randomness in there, that is
impossible to guess, then I'd
say there's not much
you can leak from that
point on. But it's something I think
it's not.
You shouldn't burden
an application developer to
be aware that their memory,
even to even be aware of the content
layout of of their program,
that most of the time very
much low level stuff that
your application developers have now
shouldn't have to have any concept
about. So I think this is really
up to the the
the operating system and hypervisor
vendors to not
use Facebook.
Thank you.
And in the back, please,
when you merge the pages,
you can have more of you can have two
in those examples. You can have more of
them code. You know which page will be
the one that will be
the last one.
So I can merge into it because it
would be good that it's the one you
control so we can select the bits.
And how do you know if you have like five
VMS and every one every has the
same page?
So so it's it's kind of
complicated. So the um.
So a sense it's the
oldest VM that gets merged
to.
But there is an exemption
if you first merge two pages
and they are put in the
first, so its first merges to already
merge pages and then it merges to the
oldest VM.
Um and so
the Saudi attack becomes harder if
you're the second VM and start to
flip thinks you need to be the first one.
So then they will merge into you.
Well, not necessarily, but the attack
becomes a bit harder because, um.
So what you could do is
if uh. So, so the merging
happens because files are in the cache.
So if you can, uh.
If the files are not yet in the cash
in the victim because
no one has tried to log in for a user for
a long time,
you might be able to first create two
pages in your own space, wait for
it to be duplicated, then
log in to assess each.
And then, as I said, you will load it in
the page and then it gets much to Europe
that you win because you're already and.
OK, thanks.
Thank you. And a question here on the
front page.
Yeah. So if I understand correctly,
the attack works only
if, you know, if you detect the
time difference between when
a copy on happens and when it does
not.
Wouldn't it be able to have
implementations of application with
some artificial timing edits
so there's no real difference.
So, um, well, the
copy on write takes time.
So there's um.
Yeah, that's probably not.
Yeah. So there's always going to be
a time difference because you don't want
to have artificial the
you don't want to artificially
slow every right operation.
That's just.
But would it be theoretically
possible to do it.
If timing is not a constraint then you
have to do all the right operations.
You have to slow them down as well.
Right.
I mean, this is not feasible in the end.
Thank you.
There is a question from the Internet.
Uh, yes.
The question is, can this be applied,
uh, for long P2P keys?
Can we link them?
Uh, so
linking the
complete contents or breaking them
or.
Uh, doesn't say so on the question,
I suppose it's about leaking them from
memory.
Um, if you can find a way
to, for example, first load them
and it really depends.
So we, uh, it takes some
effort to find the situation.
So if lots of
lots of, uh, uh,
opportunity to find
find situations where you can leak data,
but it's really difficult.
Uh, now it just
takes time to find
the right find the right
circumstances because it's just
so much you can explore.
So it's so we didn't
find, uh, so we didn't
look for, uh, um,
a situation where we could leak
keys.
Uh, so I wouldn't say it's,
uh, uh,
impossible. I do think that
some that some crypto,
uh, applications really,
uh, try to,
uh, not keep, uh,
private keys in memory longer than
needed.
So, uh,
I wouldn't know.
Maybe you can try and find
out.
I think you could write.
And then we have a last question over
here.
Please, maybe.
Do you have some advice for the Linux
kernel programmers? I think in the
second, um, example,
you said, for example, the
application used I think it was Windows
Ten was better.
They did first copy
the page to be depicted in a free speech
and then pointed the two
pages to be duplicated there.
And in Ubuntu, it
was that they just point one page
to the other and not drop the page.
So the Microsoft approach is here
more safe?
It says. So I don't know if they were
aware of this, but in this case,
maybe they were. I don't know
in this case.
And there are certainly some approaches
are, uh,
are make it harder and some approaches
make it easier.
Uh, of course, the the relocation doesn't
prevent us from leaking data, but it
would help.
Uh uh,
yeah.
Would help maybe
with with, uh, making it
harder. Although we also have
our group has a paper
on, uh, on Rosmer
on Android where we don't make use
of the application, but whether
we make use of a different,
uh, mechanism in order to control
where memory pages
are, uh, get
relocated. So yeah.
From Rehema, we can't do anything because
we have to we would have to change
the memory architecture, but
maybe you can publish some
advices. What what you do better with,
for example, memory.
What do you found you for in your
research is just an idea?
Yeah, so so there
are some, uh, mitigations.
Uh, uh, we don't know.
So my but they always have
some performance penalty drawbacks.
And so I
don't know whether they will be
implemented because.
Or are, uh,
standards. Uh, yeah.
And uh, so you
know.
OK, sorry, we have to
cut it. Thank you so much.
So please help me thank Antonio
for a wonderful demonstration.