there's a new exploit been discovered
for Linux which has got the wonderful
names called Dirty Cow as an unprivileged
user it will enable me to get root
access to the system and then i'll be
able to completely destroy it and so I'm
running Debian linux VM it's not
limited just to Debian basically any
version of linux has been released over
the last 10 years
we're going to do is show that the
exploit will give us a root shell and
then we can do some things that perhaps we shouldn't
so I'm going to first of all show by trying to change the
root password that i don't have any
permissions more than the normal
user, so I can't change the root
password i'm not going to run the
exploit it goes and visits stuff and
boom it's giving me a root shell and so
i can now if i move the right file back
in i can change the root password to
lemonade
copy the password file back into the
right place
logout of root, now back at the login
prompt and I can login as root with my
password as lemonade so I've managed to
root my VM all using the Dirty Cow
exploit
Well, to understand how it works we actually need to understand
a little bit about how the linux kernel
handles memory because what was actually
happening here is are exploiting a mech-
a mechanism that linux uses to
handle its memory and there's a what's
called a race condition in there that
when you exploit it enables you to
overwrite files that you shouldn't
normally have access to so once you can
read say things like the password file
the password program or such as every password
you can read them which is fine so you
need to but you shouldn't be able to modify
them so the first we need to think about
is how linux manages memory now we've looked at how
memory works in a computer before what
most modern operating systems including
Linux Windows MacOS etc do is that
the memory that the process uses is a
sort of logical address space it only
exists to that process the operating
system actually thinks about in terms of
pages or 4k blocks of memory which is
then maps in and out is necessary this
is how you can do virtual memory and
things and past things in and out from
disk when you need it
so if you think about our program it's
got its memory address space and we'll
say it's got memory location 0 here and
then that goes up to how ever much it's using
generally you will also have other bits
where the the operating system is mapped
as well so its got its first page there
then its second page and so on and as
far as the process is concerned these
are or continuous in memory that's
location 0 that 4K later this is 8K 16K
64K and so we just see a flat memory
address space which you can write into
in these pages. What the operating
system's doing on the other hand is it's
thinking about the physical memory and
with the help of the cpu it's got a
translation table so this is the logical
view of the process and this is the
actual physical memory so what happens
in the operating system will actually-
when it loads the program it maps that one say,
to that physical page this one may get
mapped into that one this one may get
mapped into that one, they don't have to be in
order but inside the CPU there's a
translation table which is set up by the
operating system when this process is in
memory that says map these pages in
to this location and everything works
absolutely fine now one of the things
you can then do is say well actually say
this page here has exactly the same data
in it as another page in a different
process so rather than having to use two
different memory locations in actual
memory to have the same things you can
have them both point at the same bit of
memory and we'll have the other process off
here points to the same block and if all
they ever do is read from that memory
location that's absolutely fine because
they can both read from it share it
there's no changes the problem comes to
say this process wants to modify
something in that memory location and in
that case what happens is the linux
kernel detects that it's modifying it so it's
no longer the same between the two
processes and says okay i will copy this
one into this page here this physical
page here and update the translation
table so we now point there, and because we
changed it there now pointing at two
separate locations this is what's called
copy-on-write because we copy it make
the copy when we write to the file which
is where we get the cow part of Dirty Cow
so that's what the copy on write
does in that process will copy the page
and modify it so what actually happens
with the dirty cow exploit is it uses
this copy-on-write facility but it also
does something else as well as just
being able to use the memory because the
the way that it works, you can also map a
file off disc directly into memory and
the various page faulty mechanisms used to
handle virtual memory will then load it
in when it's accessed because we've got
access to read the file we can write it
into memory and read it so we can read
the file and so we'll map the file that
we want to modify into say these memory
blocks here and these get mapped to various
pages in real memory as soon as we start
reading them or writing to them so what
we do is we map this file into memory
and we map it
simplifying the explanation somewhat in
such a way that it's mapped
so that when it gets written to
reactivates the copy-on-write so we're going to
make it maps and private fashion so
when we write to the file we get a
copy-on-write happening
we then do two things we set up two
threads running on the computer
one of which is repeatedly telling the
operating system that we no longer need
these bits of memory thing we no longer
need this bit of memory you can page it out
and use it for something else in
which case
normally you'd tell it doesn't need it
reuse the physical memory for various
things one of the things the computer
can do because it's got this translation
table and because it knows when you're
accessing it is take some of it right
back out to disk and then modify
load something else in for another process
and then swap them in and out the time
this is how virtual memory works so you can
do that behind the scenes and the
operations that so you're telling it you no
longer need this memory so it's a
candidate to be mapped out so you doing
that one thread then in another thread
linux provides access to the memory as a
special file on disk and so you open
that file up and you write the new data
that you wanted to go to that file to
the memory locations where you map that
file into memory so just write the data
you want to go there you do these things
many times a second and eventually
there's a possibility that the linux kernel
that the overlap of the two
routines happens in such a way that the
file gets updated and modified its
change and so the copy-on-write says oh
this was changed and is no longer needed
I better write this out to disk and
because this is happening as the kernel
it can write to any file regardless of
permission so writes the update out to
disk modifying the file that the actual
program didn't have the permission to
access the result being that we can
change the file on this that we
shouldn't be able to and get ourselves a
root shell or whatever is we wanted to
do with it and the reason is because the
two parts of the operating system one
that just writing to the memory and the
other which is doing the copy-on-write
and not sufficiently interweaven
interlocked so that they don't actually
stop the thing that we got what's called
a race condition between the two parts
so basically it's exploiting this race
condition
so it's kind of setting two things in
motion that kind of get out of sync is that
yeah pretty much to the way that
implementing such that the two parts of
the operating system one that just
writing to the memory and the other bit which is
doing the copy-on-write and not
sufficiently into even interweaven interlocked so
that they don't actually stop the thing
and we got what's called a race
condition between the two parts I've also
seen it crashed the kernel when trying
it as well as perhaps not as easy as all
that
it's a sufficiently serious bug if you
could ever get access to a shell on the
system you could probably if it's not
been patch get up to and get a root
shell and then do some real damage
install a Trojan, use it to form a botnet
whatever is you wanted to do so if
you've got a Linux system go and patch
it and if there isn't a patch out for it
unplug it from the network or make
sure it's well firewalled but it's a
but it's
a sufficiently serious bug that anything where you
can get access to a root shell can then
just use it it's a sufficiently serious
bugs an accident
it's a sufficiently serious bug- that's a
tongue twister if ever there was one
