my name is home of religion attack and
today I'm going to present our work
packs
check analysis framework for Venice
colonel my advisers are dr. Zhang Liang
Chow agent they see the jungle work with
dr. Irwin Borgia and a Hammond adds up
and wrong and so permission check on
trillion in axes are complex and
currently there are three different
cultural models and the first one as we
all know is very common called dak wear
which is a file-based of formation and
the second Y is called capabilities data
y is imitated to break down the route
permission into our currently we have 38
different capabilities and here is one
example so the ping commander used to
have the full group permission but now
it only has the capability of sending
raw network packet so and the third one
is called
LSM and that is short for Linux a secure
module and as well now we have 190
different hooks in the name is Colonel
and they are used to implement selinux
and IPP armor used by lots of defense
mechanisms and because that are those
hooks are actually added into the
English Colonel in ad hoc manner and so
that is hard to guarantee all of them
are placed correctly and this is a
motivation or work let's elect look at
our one example so this example is
showing the method to change a process
name so usually we can have a the first
method is to use the so-called proc file
system there is a one file called comm
as you can see here I draw a path from
the user space the right and we can call
the right to the Superman foul it has to
pass a security file permission check in
order to invoke these that has Kashiwa
now which will eventually change the
process name to a new name and there is
also another way so that is to call the
this so call the process control
a citizen called you actually to change
that name and that season Hall will call
the service Castle amateur actual
results are passing any checks so you
can see here we bypassed the security
file permission check which is actually
a problem so our goal here is to design
a static analysis to to find out all of
those kinds of formation check box
including the missing checks like I show
here and inconsistent and the redundant
information checks in order to do this
we need to enumerate all the possible
passes that can be reached by a user and
luckily we can see those possible passes
can be represented at a control flow
graph that I can - over here and the
whole problem becomes a carry numerator
all the passes using these
interprocedural control flow graph to
find out the possible paths and before
we do that and we actually need a
interprocedural control flow graph how
do you get that as we all know this is
the first challenge as we all know in
the Linux kernel there are lots of
indirect function calls so we counted in
the version four point eighteen point
five there are 115,000 indirect costs
ice and kernel frequently used those
function pointer to call the real
implementation or either it's a file
system or the driver so it's so called
the from the abstract layer to call the
concrete implementation so for example
we have way we our first layer it is
calling the F from the file it is
calling fo PS and then write either so
the possible target could be yak see for
btrfs CFS or the NFS similarly we can
help the network layer is calling the
send message according to different
particle data you are using and there
are however there there are no existing
that well or working solutions do well
the solution that used up by prowl work
is to use a type based approach so if
it's also known at the function
signature based approach to resolve the
indirect cause the downside of that is
its imprecise for example the still that
we are fast right example if we look at
the function type or the function
signature we can find out that the right
function is actually the signature it's
actually the same as read
so if we use function signature this
will result in the wrong call graph and
another approach that people have tried
or in the prior work is to use advanced
upon her analysis that does not that
will will also contain the point or
solution for not only for the the
function pointer as well and also data
pointer as well so the problem all these
are at once the pointer analysis to
either it does not grow well for the
size of Linux kernel so there are like
eight sixteen millions the lines of code
so the existing tools like the SAF does
not scale well and the people how the
people have tried to break down the
kernel code into smaller pieces so that
they can apply the SPF in a more
scalable manner and there that downside
it does it will harm the soundness so
that mean the interprocedural call graph
will be a colorful graph will be not as
soon as the previous one and the
challenge to is actually a result of the
video there is the hot manner or adding
those permission check functions or
hoops so the first thing we don't know
it the security permissions check
function is add is added in ad hoc
manner we don't know that and the second
thing is that we don't know which
function is actually intended to be
protected by those are security
permission check functions and the third
thing is that we don't know their
mapping so those are the three things as
a result of the ads hopefully add it on
the permission check function so we need
to solve that those two challenges all
right and that's look look like let's
take a look at the how they actually the
PAC's works the packs are takes into the
kernel source code compelled as a I are
they all we mi are and we first around
the keyring which is responsible for
resuming the indirect or and draw a
interprocedural control flow graph and
we use that intra procedural control
flow graph to do to so the second
challenge which will allow us to detect
all the function permission function
wrappers and the privilege functions
which is actually intended to protect to
be protected by permission check
functions and finally we will use the
ICF G and also the those mappings we
generated to detect the error so let's
let's take a look at how the keyring
works and how to actually resolve those
indirect calls the human is actually
designed based on the observation that
most of the in doubt cause we count in
the number about 90% in the Linux kernel
is actually using a well defined at the
interface data also talked about and
that means so give you example so the
for the filesystem we can have the
instructor file operations and the
kernel developer so for example the
filesystem but you are poor only need to
worry about those
those functions in order to I mean
integral to their own of the file system
into the kernel we end without worrying
about other parting the whole thousand
stack similarly for the network protocol
we only need to worry about how to
implement and the messages receive
message and so on so and so so the
queuing is actually designed in to take
one he wrote this and it can be
implemented in the two steps and the
step one
like I just add the kernel how a
well-defined such interface the thing we
need to do in the step one is to collect
all possible target for those function
pointers in the such interface so we can
see for the profile system we can how
the sill amorite being assigned to the
right function pointer there so
similarly we can have LC 4 and we FTE
and other system and so keyring
basically keep track of all those
basically you can see here it's
aesthetically neutralized and we can
also have a dynamic we initialize the
structure as well and curiam basically
keep track of all those and once we have
all those information with this thing
will be become much simpler though the
thing we need only need to do is to look
at the call side first thing is for this
step two we need to identify such
interface and so you can see this we
have a foul right example we are
actually using these file operations
that are interface and we are calling
the right using the right function
pointer inside the interface and then we
can draw a conclusion that this line is
actually trying to call a a function
that a function pointer that assigned to
that right field and based on our
digital step one we can see the possible
Holly
for this FOP right is still mmm right so
this is how the keyring works and it can
help us to so many personal the in our
cost which is pretty good so the
advantage of this approach is that its
precision is better than the type based
method as I just showed in the previous
example the type is the one will
possibly point the right to some read
function which is actually incorrect and
if we compare our hearing approach to
the existing as we have based approach
we can find out that or our approach is
much more simpler and more scalable than
the as we have based the approach so
necessarily let's took a take a look at
the rest of the packs workflow so next
I'm going to talk about how we saw
channel 2 so we actually require the
user to give us some CD input for the
permission check function and then we
will run the analysis on the I CFG we
generated to detect all the function
wrappers to that permission check
functions and we'll you that detected
permission check functions that you did
have all the privilege function so we
want to know which function is actually
protected by those permission charts and
in the next couple slides I will focus
on how we actually detect the privilege
functions so in order to detect the
privileged functions we run the analysis
on the interprocedural the control flow
graph and the first requirement for that
is the Deb has had to be user reachable
all right that's no doubt right
otherwise there is no way to trigger
that so the second thing is that the
call site all a are protected a
permission check function should
dominate another call side
that actually in the green box right
here so you can see without going
through the security file permission
that is a permission check function call
we cannot reach another cosine which is
FOP right so that means the FOP right is
actually protected by the security
profile permissions and then we will
mark the Kali oh such the green box at
the the privileged function and however
if we have another outgoing edge from
the security file permission let's see
it can call some function called bar and
there is another incoming edge from
somewhere we don't know and then so that
means without you going through this
permission check we can still call the
function bar then we cannot draw the
conclusion that the power is the
previous function so that's the result
of the the privilege function detection
and then we can use those information
that we collected and run the analysis
on the inter procedural control flow
that we generated using keyring and you
can see in the first step we use your
permission check function and we got the
privilege function in the bar but they
were bottom and once we've got that
information we will run a backward
analysis to see whether we can reach a
[Music]
system query point and for that exactly
in the past if we found out that there
is no permission check function called
then we will the taxi will reason alarm
for implementation and the evaluation we
we implemented our packs using our VM
and generated a single VM Linux dot BC
file using Java VM and we evaluated the
it is stable in the sky at the time we
write a paper and we use two different
configurations for the for testing so
it's a default configuration that
contains two font for millions of lines
of code and all yes config which
contains almost 16 million lines of code
and next let me show the detection
capability which is the most interesting
one as we can see the packs keyring
which is the are all work will detach
any one bugs for the packs with type
based in the Oracle resolution we will
also detect any one but but for the key
minor plus the plus the SPF based
approach we only did have the sixth of
them that is because the way that how
the the after we Fe is actually applied
can generally a unsound interpersonal
control flow graph and although we can
see here we have the same amount about
the detected the PAX type based one for
the next slide are here we if we compare
the number of warnings that he that
generated by type based on one and packs
keyring we can see the packs carrying
actually generates here way less number
of warnings then the the perhaps the
type based on that means the programmer
need to spend less amount of time
parsing all those warning to find out
the real bugs and there is no surprise
that the packs K minor based approach
generally some nasa number of warning
because the sound i CFG generally hit by
Dom so to conclude pack C is a static
permission check analysis framework for
Linux kernel and queuing is a very
effective way to beauty interpersonal
control flow graph for kernel analysis
and we also produced a list of
permission check functions and
related functions for developers to use
and we evaluated the latest of all a
stable Linux kernel with packs and
phones all the 36 permission check box
and that's it thank you we attempt for
about one maybe two questions well I
know get sets up alright general
chrismal University of Rochester nice
talk one question I have to ask I have
about Kieran is the call graph analysis
that it's performing is it taking
advantage of Linux isms so for example
the fact that these global data
structures are initialized once it's not
modified mmm
yeah most of them are actually
initialize and this out to the read-only
and there are cases that the you know
the URL war can be dynamically
configured so there are also cases those
fields are dynamically neutralized so we
also keep track of that yeah yeah that's
possible yeah it could also be modified
but that's rare okay from UC Irvine when
there are multiple candidates for
function points are in building your
control flow graph how do you choose
among them because the data structure
that you show maybe in some modules
there are a couple of them and you you
can't know which one which one to choose
for this oh I think probably we're all
out how we had to be off yeah
yes thank you take it offline all right
thanks let's thank our speaker once
again
you