it is 2024 and the number one cause of
hacks continues to be Memory corruption
it's also 2024 and I I just learned that
a marker like this the cap you can put
it in the bottom of the cap did you guys
know this I've just learned about this
anyway the new feature in the Linux
kernel is called mseal it's a new CIS
call that will allow the colel to
protect a page of memory so hackers
can't take advantage of it and in
classic Linux tradition it's been met
with a ton of controversy by lonus in
particular in today's video we're
talking about the M seal CIS call let's
get into it for thousands of years okay
maybe maybe not thousands but for for
you know for tens of years um the number
one way that hackers get into your
computer is by taking advantage of these
things called memory corruption bugs by
overflowing a buffer or by doing some
kind of use after free computer hackers
are able to use those vulnerabilities to
get code execution on your computer and
if anyone knows about this it's this guy
Jeff Zoo Jeff zoo is a maintainer at the
chromium organization that runs the
Chromium browser which is like the basis
of every browser on the internet and so
this guy knows a lot about the world of
memory corruption in particular because
the V8 engine that lives inside of
chromium has been a source of so many
vulnerabilities that people can use to
take advantage of the sandbox and escape
the V8 sandbox and get code execution on
a viewer's computer and so Jeff Zoo
being very familiar with this world is
aware of how poorly the world of memory
corruption attacks are are and so he
came up with this thing called mseal now
mseal is a new feature in the Linux
kernel that will attempt to address the
way that hackers take advantage of your
computer so to talk about M seal first
you have to go into how how do hacks
work how do people take advantage of
memory corruption vulnerability now
before we keep going I want to talk
about the sponsor of today's video the
UB Key by yubo one of the problems that
I deal with all the time when I'm doing
development is SSH Key Management so
with the UB key what I can actually do
is make an SSH key that lives on the UB
key itself we can do that with this
simple command here SSH key gen resident
and verify required and by doing this we
actually make a key that lives on the UB
key itself so if I were to go to a
different computer that I didn't have
the key on as long as I have the UB key
itself physically I can run this command
here that will actually extract the key
from the UB key itself and download it
locally now I can use that new key to
log into my server here which is a
server that I use for fun games on
stream I didn't have to send an SSH key
via email I didn't have to send an SSH
key in Dropbox which are all super
insecure ways of transferring keys I can
just put it into the UB key and plug it
in somewhere else if you use my link
right now you can get $5 off your own UB
key where you can store your own SSH
keys thanks again ubo for sponsoring
this video the fundamentals of basically
every memory ction vulnerability can be
seen right here we have a buffer that is
32 bytes wide and we use a vulnerable
function to put data into that buffer
now the reason that this function is
vulnerable or insecure is because it
doesn't check the length of the buffer
itself right you actually can go and do
man gets and it'll say hey by the way
never use this function bad function bad
code don't use it ever uh but despite
that you know people still manage to use
not necessarily gets gets is extremely
rare but functions like scanf for
example where if you didn't know this on
its own will produce a memory coruption
vulnerability because it also is not
checking the length of the buffer so we
can actually use this we'll compile it
it will do vul and if you're a
non-suspect user you put in 16
characters and you're like oh wow what a
great day I'm having but if you put in
more than that we're going to go way
over this so if we just keep putting
data into this thing eventually we will
put so much data in there that we are
overflowing a bunch of metadata that is
on the stack now we are seeing a stack
smashing detected error here this is
actually us blowing through what is
called the stack Canary we're not going
to go super deep into the details today
but it's important to note that there
have literally been Decades of research
into trying to give features to the
colonel to uh portable executables and
to eles which is a file the file format
in Linux to make them so that they're
not vulnerable to these kinds of attacks
you're probably wondering you know how
what what does this actually get us now
if you're not familiar with assembly
don't freak out I'm going to explain to
you exactly what is happening here but
there's a bunch of instructions in the
CPU that make the program do the thing
that it's supposed to do right and the
two major ones here are leave and R
these are the two instructions in the
32-bit and 64-bit calling convention for
uh for Intel that make the CPU go back
to the place that it came from because
if we look at the code for V.C there's
this function main well actually in the
program startup there is a function in
libc in the main library that called me
so we need to have a way of getting back
to that to that function right and this
instruction does that the problem here
and again the basis of every memory
corruption vulnerability is that this
instruction takes the data off of the
stack now the stack is what again the
stack is the location that we are
exploiting by putting too much data into
it so effectively if a hacker is able to
put enough data onto the stack they can
corrupt the location where the return
address lives and return to their own
code this is where another mitigation
comes in if we do read elf on our
program we're going to get a bunch of
the metadata about the program itself
and the one thing that we'll see is we
have these things called program headers
program headers describe the permissions
of the data that is going to get loaded
into the computer right and we'll see
here we have this thing called the gnu
stack and again the stack is that memory
region that contains all of the data
that we are using to do our overflow you
will notice that the data is readable
and writable but it's not executable why
is that well the reason being for a long
time that we didn't have this idea of
memory corruption vulnerabilities like
hackers were not at the Forefront of
thought when it came to Computing and
for a long time a lot of memory Pages
like the stack for example were readable
writable and executable at the exact
same time now what this allowed hackers
to do is use a memory corruption
vulnerability and what they could do for
example is when they're doing their
buffer overflow they would put their own
malicious code in that buffer they would
do all the A's to overflow it and then
they would say in the return address
return to my code they would put the
pointer to their code and it would run
it immediately so the thought from
computer Architects at the time was like
okay if we just reduce the amount of
pages that are writable and executable
exclusively we call that NX
non-executable then we give them less
places to put malicious code and this
does work for a majority of things like
this makes the attack surface and the
amount of work required to do memory
corruption vulnerabilities extremely
hard it adds an entire layer of
complexity until recently until the last
10 or so years where this IDE aide
called return oriented programming came
out now what you'll see is that we have
these things in our code that are called
gadgets it something something happens
and then we R something something
happens and we call R for example so we
have ADD RSP 8 and R right because these
Snippets of data are executable we can
jump around the program using those
gadgets and effectively write our own
program using the code that already
exists we can do pop register R we can
do call function R and that all allows
us to write our own code the ultimate
end State when people do return oriented
programming attacks is to call this
mythical function here M protect and
you'll see M being M protect you'll see
that M protect and M seal are linked
we'll get to that M protect is a
function that allows you to specify an
address a length and set the permissions
of that page now remember previously I
said that we have a stack that is only
readable and writable well what if
through M protect I can make it readable
writable and executable I can do that if
I have enough Dr gadgets to return to M
protect I can use this function to make
the stack executable and then jump to my
long snippet of code incredible right
and so this has been kind of the
Paradigm for for hackers for a long time
we have the snippet of code and we are
able to use it to over to change the
permissions on the stack and so Jeff zoo
is like hey why don't we just not do
that why don't we just make it so that
you can't edit the permissions of the
memory pages mseal so what we do is this
new function mseal will have a address
and a length and the flags associated
with it a bunch of different flags for
the function call and it will make it so
that you cannot change the permissions
of the page and so after you've sealed a
memory page you cannot unmap it you
cannot move it or expand it this is a
problem for a few reasons let's talk
about the here in a second you cannot
modify a virtual memory map via M map
you cannot expand it you cannot call M
protect or pey M protect and you cannot
do destructive M advices and this will
return a error permission from the
colonel if you try to do any of these
after a page has been sealed now when
this came out in classic less tval
fashion he was not a huge fan all of
this is completely nonsensical yada yada
y he kind of rambles about there were
some initial issues with the design of
it but eventually this was back in
October um of 2023 so a year ago it is
now going to be released in G liy uh 241
in February of next year classic to
Classic Toral no more random code no
more random seals none of this crazy you
exstensively can't unmap a VMA but you
can unmap it by unmapping over it and
unmapping a new one so again he he this
is his baby you have to understand that
like he has been doing this for a long
time and as a result he is very
passionate about about his code base now
a few issues with mseal the reason why
mseal can't just be used anywhere is for
a few reasons you cannot expand or
shrink a page allocation size with M
remap after calling M seal the way the
Heap works it actually is required that
the memory page that the Heap lives in
has to be expandable so while the CIS
call will come to be in JB c241 the
stack in the Heap are not going to be
sealed out of the box because it'll
actually break the functionality of how
the Heap and the stack grow but kind of
a cool idea I think we are trending
towards having enough features in the uh
in the G GC runtime to make it very
difficult to um to do memory corruption
bugs now obviously we are still
protecting software with software and
that is going to leave us and that kind
of leaves us in this weird cat and mouse
game we will perpetually just be looking
for new ways to break these things um
but either way we are truly hardening NX
again the idea that code should never be
writable and executable um and I think
that's pretty neat so if you like the
stuff or just want to hang out more in
the future or learn more about hacking
or literally whatever hit the sub button
I appreciate it and then go check out
this video that I think you will find
equally as interesting we'll see you
over there thanks guys