►
Description
Kubernetes Community Days Bengaluru'21
We interact with the operating system kernel in many different ways, by reading from the file system, opening a device file, issuing system calls, or sending a packet over the network interface. Each time the kernel does this on behalf of user space, it checks if the user has permission to call that action by checking privileges. Kernel privilege escalation is a process of obtaining additional permissions by exploiting a weakness in kernel code. In this talk we’ll explore what kernel privilege exploits are, look at an example in practice, and then show the different ways in which containers and Kubernetes can help to reduce the impact of these kinds of exploits.
Slides: https://docs.google.com/presentation/d/1cEUuzSfIkhMFCpgSV02xDkNHqLp066DokYnfu_rclYs/edit?usp=sharing
B
A
A
So
when
we
talk
about
operating
systems,
we're
describing
the
core
software
that
provides
the
interface
between
the
computer
hardware
and
the
end
user,
and
whilst
operating
systems
may
ship
with
end
user
applications
in
them
like
windows
or
on
mac
os
in
the
computer.
Science
sense
we're
talking
about
the
programs
that
enable
applications
to
run
on
the
hardware,
and
this
would
usually
consist
of
the
operating
system
kernel
and
various
utilities
and
libraries
that
perform
the
base
functions
of
operating.
The
computer.
A
And
the
kernel
is
right
at
the
heart
of
this:
it's
the
first
thing,
that's
loaded
by
the
bootloader
when
we
start
the
computer
and
it's
always
resident
in
memory.
The
function
of
the
kernel
in
general
is
to
handle
interactions
between
software
and
hardware,
so
everything
from
managing
the
cpu
reading
and
writing
from
disk
and
handling
packets
on
the
network,
and
this
is
a
little
old
diagram.
But
fundamentally
this
is
how
the
boot
process
works
in
a
linux
system
and
the
bios
is
firmware.
A
From
that
partition,
I
mean
in
this
case
it's
a
bootloader
grub
and
then
the
bootloader
will
then
load
the
kernel
and
once
the
kernel's
running
it'll
load,
what's
called
an
initialization
daemon,
which
then
handles
all
the
starting
of
other
system.
Software
and
the
system
is
then
up
and
running
in
modern
linux
systems.
The
the
init
is
is
usually
system
d,
but
this
is
this
is
the
kind
of
a
typical
pattern
of
operation.
A
So
if
all
of
our
applications
access
the
hardware
directly,
you
can
imagine
that
things
would
get
pretty
complicated
and
the
potential
for
things
to
go
wrong
would
be
huge.
While
some
historical
computers
used
to
work
like
this
in
general,
they
ran
single
applications.
So
there
wasn't
that
much
of
a
need
to
manage
access.
A
A
That
means
that
the
cpu
switches
between
applications
to
keep
them
all
running
all
of
the
time
and
the
cpu
is
only
ever
really
executing
one
thing,
but
it
happens
so
fast.
This
switching
that
it's
invisible
to
the
end
user,
so
it
looks
seamless
to
us
when
it's
happening,
and
what
actually
happens
is
that
as
each
process
needs
time
from
the
cpu
or
to
interact
with
something.
The
kernel
basically
saves
the
the
program
state
into
these
process.
A
Control
box
pcbs,
switches
process
executes
what
it
needs
to
saves
that
processes
state
into
another
pcb
and
then
switches
back
to
the
original
process,
reloading
its
state
from
that
pcb
and
and
so
on,
and
operating
systems
in
general
separate
their
memory
into
kernel
space,
which
contains
the
kernel
and
and
things
like
device
drivers
and
user
space.
It
contains
all
of
the
other
running
applications
and
the
processor
prevents
applications
from
accessing
kernel,
space
or
or
each
other's
memory,
and
this
is
the
basis
for
memory
protection
for
stopping
programs
from
stomping
all
over
each
other.
A
This
also
enables
privilege
separation
so
allowing
different
things
to
have
different
permissions
to
do
things
inside
the
operating
system
in
general
applications
don't
talk
directly
to
the
kernel.
Instead,
the
kernel
provides
an
abstraction
layer
for
applications
to
access
known
as
syscalls,
and
these
provide
an
interface
for
applications
to
ask
for
things
like
writing
to
the
disk
sending
packets
over
the
network
and
when
an
application
performs
a
syscall.
The
cpu
will
make
the
switch
from
user
space
to
kernel
space,
and
this
mechanism
is
known
as
context.
A
B
B
Our
goal
in
this
exploitation
exercise
will
be
to
change
the
uid
and
group
id
from
a
any
value
to
zero.
Zero
represents
the
root
permissions
on
the
linux
system.
First
step
in
our
process
is
to
identify
vulnerability.
These
are
examples
of
some
vulnerabilities
that
happen
in
the
past
that
led
to
a
privileged
escalation
exploits
as
you
can
see,
these
occur
more
or
less
once
a
year.
These
are
some
of
the
website
where
you
can
find
proof
of
concepts
for
these
vulnerabilities
and
see
how
the
code
looks
like
in
real
life.
B
So
once
we
know
that
there
is
a
vulnerability,
we
need
to
be
able
to
reach
it
and
in
kernel
we
can
do
that
by
trying
to
execute
a
system
call
which
then
enters
into
kernel
space
remotely.
We
can
trigger
that
by
sending
network
packets
to
the
machine
which
then
going
to
be
processed
by
the
kernel
as
a
first
place,
and
we
can
also
do
that
via
the
bpf
programs,
which
are
loaded
into
the
kernel
and
execute
code
in
that
memory.
Space.
B
B
If
specific
conditions
are
not
met
and
address
layer,
randomization
will
change
locations
of
certain
functions
within
the
kernel
to
prevent
you
from
finding
out
and
executing
them
page
table.
Isolation
prevents
separates
memory
pages
from
being
accessible
in
certain
regions.
So,
for
example,
when
you're
in
a
kernel
space,
you
should
not
be
able
to
see
user
page
tables
which
prevents
you
to
do
some
of
these
exploits
next.
We
also
have
the
kernel
is
a
complex
state
machine
and
it's
got
a
scheduler.
B
It's
got
a
memory
system
that
does
a
lot
of
operations
very
quickly.
All
of
these
operations
can
change
memory
layout
and
cause
our
exploits
to
misbehave
and
finally-
and
the
last
thing
we
need
to
be
able
to
do
is
to
return
the
control
of
our
exploits
back
to
the
user.
When
we
exploiting
these
issues
in
the
kernel,
we
need
to
be
able
to
send
some
sort
of
signal
to
the
user
so
that
they
can
take
control
and
execute
further
actions
in
local
execution.
B
This
means
usually
spawning
a
shell,
a
control
terminal
for
the
user
in
the
remote
exploitation.
This
means
sending
packets
to
remote
system,
usually
called
control
systems
so
that
they
can
send
more
instructions
from
the
attacker
click
on
next.
Okay.
So,
in
our
demonstration,
what
we
have
set
up,
we
have
a
kubernetes
cluster
deployed
with
cubes
spray
and
ansible.
Our
worker
nodes
are
running
a
ubuntu
system
and
we're
still
using
docker
as
our
container
runtime.
B
So
we
all
are
familiar
with
concept
of
pods
pods
run
one
or
more
containers.
However,
in
a
linux
space
there
is
no
construct
of
container
to
the
linux
kernel.
Containers
are
simply
processes
that
are
then
controlled
with
control
groups,
name
spaces
and
and
capabilities
to
form
a
abstract
container
layer,
which
is
pretty
much
a
sandbox
from
for
the
normal
user
we
go
next.
In
our
example,
we
will
be
using
a
old
vulnerability
from
2017..
B
The
privilege
escalation
in
the
kernel
usually
involves
setting
the
credentials
struct
with
a
value
zero.
This
pattern
of
system
calls
allows
us
to
perform
this
quite
easily.
Once
we
have
executable
rights
in
in
the
kernel
so
commit
kernel.
Correct
and
prepare
cannon
credits
is
a
common
pattern.
When
we
see
privilege
escalation.
B
A
B
A
flag
on
the
system
to
showcase
that
it's
not
readable
by
our
current
user.
As
you
can
see,
it's
a
permission
denied
error,
because
it's
only
readable
by
the
root
user
we're
going
to
trigger
our
exploits
it
runs
quite
quickly,
and
but
what
you
can
see
now
is
that
we
have
root
permissions
and
we
can
access
the
flag
on
the
system.
So
we've
gained
additional
permissions
by
exploiting
vulnerability
in
the.
B
B
B
B
B
B
B
B
B
In
order
to
do
that,
we
need
to
expand
our
exploit
code
to
introduce
new
system
calls,
and
now
we
need
to
identify
what
is
the
host's
namespace
id
endpointer
and
overwrite
these
with
our
current
process.
You
can
find
these
under
the
proc
file
system
and
therefore
these
system
calls
will
allow
you
to
identify
and
replace
them.
B
We
cannot
access
it
from
the
hosts
because
we
don't
have
the
permissions.
We're
now
gonna
execute
a
bus
shell
within
our
pod.
Again,
we're
gonna
see
that
on
a
file
system
within
the
host,
we
only
see
a
one
file
now,
so
we
definitely
in
the
container,
we're
gonna
run
our
improved
exploit,
and
what
we
can
see
now
is
that
we
again
we
have
root
permissions,
but
when
we
list
files
on
the
file
system,
we
see
more
files,
we
see
not
only
both
lags,
but
we
also
see
the
boot
images
that
belong
to
the
host.
B
Calico
in
order
to
prevent
some
of
these
exploits
kubernetes
exposes
some
security
controls
that
are
linked
to
the
linux
controls.
One
of
those
are
capabilities.
We
can
drop
almost
all
process
capabilities
by
specifying
security
context
capabilities
flag.
Unfortunately,
for
some
exploits
that
is
not
enough.
In
our
example,
we've
shown
that
dropping
all
capabilities
didn't
prevent
us
from
reaching
the
vulnerability.
B
The
second
security
control
that
we
can
implement
is
seccomp.
Segcomp
is
a
filtering
system
that
filters
out
system
calls
that
are
preventable
by
default
on
kubernetes.
A
second
runs
with
unlimited
filter
list,
which
means
you
can
execute
any
system
calls
you
want,
but
you
can
specify
security
context
to
add
a
default
filter
which
will
prevent
some
of
these
exploits
and,
as
you
can
see
in
a
second,
it
helps
in
preventing
the
exploit
that
we
have
created
and
the.
B
B
B
B
B
B
B
So
what
else
can
we
do
except
containers?
There
are
additional
features
that
can
be
deployed.
Cutter
containers
and
firecracker
introduce
a
lightweight
vms
as
a
runtime
construct,
instead
of
using
just
containers.
This
means
that
each
pod
runs
its
in
on
kernel
and,
in
turn,
any
exploits
cannot
escape
into
the
node
because
they
only
apply
to
the
pod
and
gviso
is
additional.
B
A
Yeah,
I
think
this
is
me
camille.
So,
as
we've
seen,
the
these
kernel
level
exploits
are
pretty
powerful
and
and
have
the
potential
to
escape
our
containerization,
the
only
real
weapon,
as
camille
said
we
have
against
this,
is
to
upgrade
our
kernels
and
to
make
sure
we're
using
linux
security
modules,
implementations
like
seo
linux
or
app
armor.
Luckily,
this
type
of
vulnerability
is
is
fairly
rare
in
comparison
with
with
more
common
application
level,
vulnerabilities
and
security
context.
A
Settings
in
our
kubernetes
configuration
provide
us
with
settings
which
can
reduce
the
the
blast
radius
if
our
containers
do
get
attacked.
So
these
principles
of
not
running
your
containers
as
root,
disallowing,
privilege
escalation
and
always
following
the
principle
of
least
privilege,
like
start
with
disallowing
everything
and
then
work
your
way
back
to
finding
the
minimum
set
of
capabilities
that
your
application
requires
and
tools
like
snake
can
help
here
by
scanning
your
your
kubernetes
yaml
files
and
detecting
those
insecure
settings
before
your
containers
are
deployed
to
production.