►
From YouTube: Insecure Containers? Continuous Defense Against Open Source Exploits [A] - Andrew Martin
Description
Insecure Containers? Continuous Defense Against Open Source Exploits [A] - Andrew Martin, UK Home Office
Open Source Software underpins the internet and many enterprises, but has repeatedly proven itself vulnerable to accident and tampering. High impact exploits lead us to question our unreserved trust in Open Source, and the wisdom of its proliferation is being questioned. As we fight to continuously secure millions of servers against these waves of attacks, have we found a crucial panacea in containers?
This talk examines the anatomy of major vulnerabilities, demonstrates their applicability to containerised applications, and explores container native security tooling throughout the pipeline.
About Andrew Martin
Andrew is a DevOps Lead in the UK Government with a strong test-first engineering background gained developing and deploying high volume web applications. Proficient in application development, and Unix systems architecture and maintenance, he is comfortable profiling and securing every tier of a bare metal or virtualized web stack, and has battle-hardened experience delivering containerised solutions to enterprise clients.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Right
good
afternoon,
if
any
of
you
were
in
Jesse's
talk
just
a
few
minutes
ago,
I'm
going
to
cover
some
of
the
same
thing,
so
we're
still
going
intercept.
Comm
set
comp
they'll,
be
a
live
demo
ever
contain
a
breakout,
but
it's
going
to
go
a
little
bit
more
low
level
based
on
all
the
work
that
she's
done
for
us
at
Google
already
right,
so
I'm
Andy,
I'm
dev,
like
second
job,
see
I'm
from
the
UK
government,
so
they
were
speaking
in
a
personal
capacity
and
security.
It's
just
a
line
item
on
my
job
description.
A
What
are
open-source
exploits
the
vulnerabilities
in
commonly
used
open
source
code
that
can
be
used
to
gain
access
to
a
system
that
is
not
permitted
and
the
question
of
in
secure
containers
do
they
really
contain?
How
can
they
contain
and
how
have
they
defended
against
major
recent
vulnerabilities
I
usually
expect
that
data
is
safe
when
they
hand
it
over.
A
So
we
asked
the
question:
is
it
possible
to
protect
all
user
data
sure
your
users
should
expect
some
level
of
privacy,
but
we
can't
protect
our
data
if
there
are
bugs
in
code
parts
and
it's
bug-free
code
possible?
Well,
it
seems
probably
quite
unlikely,
so
by
extension,
is
anything
secure
or
to
lower
the
bar
is
anything
secure
from
teenagers
with
all
these
leaks
of
personally
identifying
information
over
the
past
few
years?
Is
our
data
even
more
secure
than
it
was
30
years
ago?
A
So
this
talk
is
about
security,
the
anatomy
of
some
recent
open
source
vulnerabilities.
How
containers
affect
that
security
model
the
CI
pipeline,
tooling?
We
can
use
to
protect
ourselves
and
defense
from
future
vulnerabilities
so
quickly.
What
is
security?
It's
a
question
of
availability.
We
can
access
what
we
want
when
we
want
to
the
integrity.
Data
can
only
be
edited
by
those
authorized
to
edit
it
and
confidentiality
it
can
only
be
accessed
by
those
authorized
to
edits.
So
it's
full
control
and
knowledge
of
a
system
without
C
data
that
it
contains.
So
to
achieve
security.
A
We
must
trust
certain
parties,
they
encrypt
our
data
in
transit
and
it
rests
public
trusted
routes
towards
operating
systems
and
some
closed
source
operating
system,
firmware
vendors,
etc.
Various
protocols
open
standards
compilers.
They
were
trusting
these
guys
not
to
have
bugs
the
break
our
security
models
and,
most
importantly,
open
source
code
that
we
can
see
and
audits,
and
ideally
that
has
been
audited,
although
often
when
it
hasn't.
So
why
do
we
use
open
source?
It's
security,
one
of
those
reasons.
Linna
says:
law
states
given
a
large
enough
beta,
tester
and
co-developer
base.
A
Almost
every
problem
can
be
characterized
quickly
and
the
fix
obvious
to
somebody
so
while
open
source
software
has
the
potential
to
be
more
secure
than
its
closed
source
counterparts,
simply
being
open
source
is
no
guarantee
of
security,
but
does
more
secure
even
matter
when
we
want
a
hundred
percent
security.
There's
anything
completely
secure.
Recent
breaches
suggest
knots.
So
let's
examine
some
of
those
from
the
past
few
years,
we'll
go
through
funder
abilities
with
a
focus
on
webserver
and
container
exploitation,
their
impact
and
mitigation
and
we'll
see
what
part
containers
have
to
play.
A
You
may
have
seen
the
recent
glut
of
overhyped
logo
vulnerabilities.
Do
these
provide
any
value?
Well,
probably,
they
probably
give
more
exposure
to
vulnerabilities
and
guess
this
admins
to
patch
them
quicker
security.
Researchers
work
relatively
hard,
so
if
you'll
give
them
a
pass,
I'd
appreciate
it
for
the
purpose
of
this
talk,
all
the
vulnerabilities
discussed
here
will
have
affected
you
or
a
server
that
you
administer
or
have
come
into
contact
with.
A
So
heart
bleed
a
catastrophic
floor
in
open
SSL,
a
commonly
used
encryption
library
referred
to
as
a
modest
code
base
of
outsized
importance.
This
was
considered
theoretically
and
exploitable
by
ironically
enough
CloudFlare
more
on
them
later,
and
an
attack
proven
inside
nine
hours
when
they
opened
a
competition
to
see
if
anyone
could
actually
exfiltrate
their
server
keys.
It
affected
twenty-five
to
fifty
percent
of
all
major
sites,
its
closure
and
is
a
problem
in
ssl.
Heartbleed
heart
beat
handling,
so
a
heart
beat
is
sent
by
the
client
to
the
server
to
maintain
a
persistent
open
connection.
A
In
this
case,
the
user
sends
an
expected
reply
word
along
with
the
length
of
that
word.
Obviously,
that
should
be
validated
on
the
server
side.
It's
untrusted
user
input.
In
this
case
the
example
is
hats,
and
the
length
is
five
hundred.
So
the
server
replies
with
the
word
hat
in
memory
and
their
leaks,
the
next
five
hundred
bytes
private
data,
that's
private
data
that
could
contain
private
keys
information
about
other
connections,
essentially
not
something
that
line
is
permitted
or
authorized
to
access.
A
So
a
malicious
user
specifies
a
false
length
and
we
potentially
leak
all
sorts
of
data.
You
do
this
attack
enough
times
because
it's
in
the
initiation
phase
of
the
protocol-
it's
not
reported
in
logs.
It's
just
seen
as
an
aborted
connection,
collect
enough
data
and
you
can
piece
together
the
private
keys
and
other
contents
of
memory.
So
the
poor
guy
involved
valid
that
missed
validating
a
variable
containing
a
length.
A
A
relatively
easy
mistake
to
make,
especially
in
see
reading
more
data
than
one
is
permitted,
is
called
a
buffer
overrun
and
this
particular
bug
was
discovered
by
fuzz
testing.
The
open,
ssl
library
with
american
fuzzy,
lock
and
another
tool
called
dress.
Sanitizer
from
google,
a
father
is
something
that
sends
a
huge
amount
of
untrusted
data
check
code
paths
that
potentially
aren't
checked
by
the
application
code.
Afl
is
a
relatively
advanced
fuzzer
and
requires
the
software
target
to
be
recompiled
with
extra
code.
A
It
will
then
track
with
branches
of
code
of
follows
and
use
a
genetic
algorithm
to
try
and
explore
as
much
of
the
problem
space
and
as
short
a
time
as
possible.
Address
sanitizer
just
turns
memory,
access,
errors
and
crashes.
So
FL
knows
that
it's
done
something
that
it
shouldn't
have
done.
So
the
user
mitigation
for
heartbleed
was
update,
OpenSSL
reissue
and
redistribute
your
security
keys,
so
the
questions
was
OpenSSL
more
secure
for
being
open
source.
A
Anecdotally
many
closed
source
vendors
who
didn't
disclose
that
they
used
the
open,
SSL
library
quietly
updated
around
that
time.
So
containers
don't
really
help
open
SSL.
The
hosts
memory
was
protected,
but
heartbleed
leaks
process
memory
anyway,
ie
the
web
servers,
so
the
containment
is
not
really
effective.
Heartbleed
is
essentially
indefensible
where
the
container
as
the
checks
not
at
the
right
level,
it's
an
attack
on
the
implementation
of
a
spec
and
the
application
itself,
but
containers
do
help
because,
presumably
we
have
fast
redeployment,
cih,
DD
pipelines
and
the
time
it
takes
to
ship.
A
A
change
from
test
through
to
production
should
be
dramatically
reduced.
The
silver
lining
so
in
kernel
in
container
terms,
heart
bleeds
is
like
building
a
castle,
securing
the
walls
and
having
the
guards
give
away
the
secrets.
So
the
next
vulnerability
shellshock
a
bash
shell
vulnerability,
allowing
privilege
escalation.
This
adds
code
to
a
specially
crafted
environment
variable
which
is
then
executed
in
the
wrong
context
and
potentially
privilege
escalated.
A
So,
while
heartbleed
leaks,
data
shellshock
can
be
used
to
take
over
the
host
system,
some
impact,
CGI,
Web,
Apps,
sshd
and
basically
all
Linux
boxes
or
pre
SD
boxes
and
all
UNIX
boxes,
post,
1991
and
all
Mac's,
basically
the
world
for
all
of
us
here,
although
Debian
Ubuntu
or
less
vulnerable,
because
they
don't
use
bash
by
default,
Alpine
installs
busybox.
So
you
only
have
a
bash
like
so
some
distributions
by
default
will
less
vulnerable,
is
a
demo
of
worse
a
static
demo
of
an
HTTP
request
that
demonstrates
the
shellshock
bug.
A
So
on
the
first
line
you
see
the
user
agent
containing
the
exploit,
payload
we've
got
parentheses
and
then
another
set
of
curly
braces
with
an
O
up
in
the
middle.
Then
closing
off
that
initial
function
call.
Then
we
execute
bashed
ping,
ID
cat
ECC
password
his
burps.
We
output
showing
the
server
responding
because
the
payload
came
through
in
header.
Unless
the
target
targeted
server
was
recording
all
HTTP
headers,
which
is
infinitely
rare,
then
this
would
insure
from
the
logs.
A
So
this
bug
was
in
the
initial
implementation
of
function,
importing
and
exporting
written
by
bashes
original
author
before
HTTP
existed
before
the
web
was
born
and
before
Linux
shipped
version
1.
That
was
the
25th
of
August
91.
So
it
would
be
incredible
if
this
bug
was
not
being
exploited
in
the
wild
during
that
25
year
window,
a
lot
of
CDs
were
found
around
that
time
and
finally,
fixed
by
Florian
were
more
of
red
hats.
A
He
said
he
found
the
bug
after
reflecting
on
an
earlier
vulnerability
of
a
similar
type
and
bash,
and
of
note
is
that
the
latter
two
bugs
on
this
list
were
also
discovered,
with
American
fuzzy
lock.
The
mitigation
upgrades
was
this
more
secure
for
being
open
source?
Well,
probably
not
because
it's
been
in
the
wild
for
so
long,
so
many
eyes
had
looked
at
it.
Maybe
there's
a
FAL
ability
and
allowed
Linux
is
law
there,
but
did
containers
help
absolutely
they
isolated
the
process
into
the
container
running
the
webserver.
So
the
host
was
him.
A
The
host
was
isolated
in
the
impact
cushioned
assuming
no
further
privilege
escalation
vulnerabilities
as
opposed
to
heartbleed.
This
is
a
remote
command
execution,
so
we
can
contain
the
command
when
it's
run
on
our
servers
and
protect
the
hosts.
Back
to
the
castle
metaphor,
the
perimeter
is
secure,
but
this
is
akin
to
allowing
a
Trojan
horse
through
the
gates
of
the
castle,
but
locking
it
in
the
dungeons.
A
The
malicious
contents
spilled
out,
but
they
can't
get
any
further
than
the
jail
that
they've
been
placed
in.
The
next
vulnerability
drown
an
attack
on
TLS,
which
stands
for
decrypting
RSA
with
obsolete
and
weakened
encryption,
because
it's
a
protocol
attack
similar
to
heartbleed.
It
can't
be
defended
with
containers.
The
problem
here
is
old.
Us
export
grade
cryptography
on
symmetric,
ciphers
33%
of
all
sites
were
vulnerable.
A
disclosure
mitigation
say
blessed
salvation.
It
was
enabled
in
the
first
place
and
upgrade
openness,
so
changing
any
secrets
that
may
have
been
leaked
as
a
side
note.
A
There
are
a
lot
of
TLS
vulnerabilities
that
containers
can't
help
with
and
why
so,
many
and
why?
The
cluster
after
May
23rd,
our
dear
friends,
Edward
Snowden
post,
these
revelations
have
renewed
vigor,
has
been
applied
to
TLS
libraries
in
the
fear
that
they're
all
back
doored
so
develops
fear,
but
throughout
the
search
for
intentional
or
accidental
vulnerabilities,
still
allowing
outdated
ciphers
on
their
hosts
is
TLS
more
secure
for
being
open
source.
Well,
this
is
the
cavalcade
of
academics
and
researchers
that
were
required
to
combine
their
expertise
to
identify
this
vulnerability.
A
So
undoubtedly,
yes,
although
the
complexity
of
attack,
probably
meant
it
was
the
remit
of
state-sponsored
actors
back
to
the
castle.
This
is
like
securing
the
entrance
to
the
castle
with
an
obstacle
only
allowing
people
over
a
narrow
and
secure
bridge
and
then
being
surprised
when
emojis
drains
and
thinking
it
continues
to
provide
any
security
and
containers
help
it's
a
protocol
attack
and
no
amount
of
containers
will
help
us
from
miss
implementations
or
vulnerabilities
and
specifications.
A
The
only
benefit
we
reap
is
quick
redeployment,
so
the
next
vulnerability
dirty
cow.
This
is
a
linux
kernel,
bug
which,
when
exploited,
gives
root
on
every
kernel.
Since
2007
was
this
more
secure
for
being
open
source,
probably
not
considering
how
centrally
important
that
piece
of
code
is
the
amount
of
reviewers
required
to
sign
off
pache
and
the
amount
of
people
using
the
code.
A
So
the
URL
is
dirty
Cal,
dot,
ninja,
truly,
the
worst
of
all
logo,
vulnerability,
URLs
and
it's
a
race
condition
in
the
copy
on
write
code
in
kernel
memory,
mappings
again,
it's
on
every
Linux
device
embedded
Linux
devices
probably
have
no
path
to
upgrade
from
this
book,
so
the
severity
is
still
impacting
today.
Exploitation
of
this
bug
doesn't
leave
any
trace
in
library
and
logs,
and
the
mitigation
is
once
again
upgrade
so
of
notes.
This
bug
was
found
in
the
wild
by
the
research
were
involved
by
recording
all
the
packets
coming
into
his
server.
A
One
of
his
sites
was
compromised.
He
was
running
a
rolling
packet
capture
and
he
reconstructed
the
binary,
ran
it
in
a
sandbox
and
then
submitted
it
back
to
you
were
back
to
the
Linux
mailing
list,
so
how
containers
helped
well
containers
didn't
contain.
The
spoke
containers
rely
on
the
kernel
for
protection
they're,
just
an
extension
there's.
Only
a
single
kernel
shared
between
all
the
containers
running
on
a
host,
so
namespace
and
C
groups
are
beneficial
up
to
a
point.
A
But
when
there's
a
bug
in
one
of
those
pieces
of
code,
it's
very
difficult
to
protect,
protects
against
and
go
through
a
demo
showing
how
you
can
break
out
using
this
exploit
and
how
you
can
prevent
that
in
a
few
moments.
So
back
to
the
castle,
it's
like
building
a
cost
on
the
biggest
rot.
You
can
find
being
surprised
when
someone
tunnels
in
from
underneath
the
kernel
lets
the
containers
guard
down
and
there's
very
little
that
can
be
done
by
default.
A
A
The
fix
again
is
to
upgrade
docker
and
the
honorable
mention
goes
to
cloud
bleed,
revealed,
Friday,
the
24th
of
February,
an
error
and
an
HTML
parser,
triggered
the
same
error
as
heartbleed,
a
buffer,
overrun
and
leaked
private
data
in
the
response
interpolated
with
HTML,
and
there's
some
disagreement
over
how
vulnerable
or
how
exploitable
this
actually
has
been.
The
amount
of
data
leaks.
Nevertheless,
was
it
more
secure,
an
open
source?
Well,
it
wasn't
open
source.
Would
it
being
more
secure,
possibly
enough
people
running,
it
would
probably
have
identified
the
bug
at
some
stage.
A
Obviously,
you'd
be
catching
this
with
a
strange
kind
of
integration
test,
so
it's
difficult
to
catch
at
a
lower
level,
but
there's
no
way
in
a
month
of
Mondays.
The
containers
would
help
it's
an
application
issue
and
containers
containing
processes,
not
portions
of
their
memory.
So
what
do
these
vulnerabilities
have
in
common
humans?
Inevitably
making
mistakes?
The
people
that
reported
these
bugs
were
generally
not
on
the
project
teams.
So
lines'
law
has
some
benefits
here.
Opening
up
to
more
eyes
results
in
greater
shared
understanding,
fuzzing
application
yields
fantastic
results.
A
American
fuzzy
lot
found
a
huge
amount
of
vulnerabilities.
If
you
look
at
their
homepage,
they've
got
a
laundry
list
of
products
that
they've
owned
and
containers
not
a
panacea
as
I'm
sure
we
all
know
there
are
plenty
of
vulnerabilities.
They
either
cannot
stop
or
are
not
configured
to
stop
and
move
on
to
that
shortly.
A
So,
let's
demo
a
contain
a
breakout.
This
is
potentially
the
most
insane
attack
to
demo
because
it
relies
on
a
race
condition
and
I'll
demo
it
inside
a
VM
on
my
laptop,
which
is
stepping
down
CPU
on
battery
mode,
but
it's
the
most
recent
and
probably
the
most
dangerous
all
linux
kernel's
since
2007
all
docker
versions.
A
A
A
Dtrace
in
an
effort
to
essentially
trick
the
kernel,
where
there's
the
brief
moment,
where
it's
possible
to
write
to
memory
that
is
being
changed
from
root
privilege
to
user
and
at
the
moment
where
it's
still
writable
by
the
you
becomes
writable
by
the
user
before
it's
lost
its
privilege
of
root
access.
So
it's
copy
on
rights
and
the
race
condition
is
getting
in
there
just
before.
The
permissions
have
changed
entirely
in
this
Cystic
window.
We're
tracing
port
1,
2,
3
4,
which
is
where
once
the
exploit
inside
the
container
has
managed
to
trick
the
kernel.
A
A
So
what
we've
done
here
is
build
a
container
with
the
dirty
cow
virtual,
dynamic,
shared
object
exploits
in
it,
and
this
is
going
to
tell
us
what
vulnerabilities
we
have
on
this
kernel
version.
So
it's
an
old
version
42
and
there
are
various
other
things
that
are
wrong
with
it,
we're
just
going
to
focus
on
data
cow.
For
now
we
want
to
run
with
a
barber.
Well
that
gives
you
a
clue
what
we'll
do
later
for
now.
A
No
so
we're
off,
we've
got
the
Emin
vehicle,
which
the
memory
advised
P
Trace
is
attempting
to
trace
the
application
from
within
itself
to
inject
this
code
being
a
race
condition.
You
can
see
it's
still
1034
47.
This
is
way
behind
where
we
actually
are
because
of
the
huge
volume
of
calls,
and
then
we've
got
the
listener
open
here
on
globs
to
all
adapters
and
one
two,
three
four
and
there
we
go
so
we've.
Now
you
can
see
at
the
top
we've
managed
to
backdoor
the
V
s.
A
So
you
can
see
it
bottom,
hopefully
not
yep,
that
file
is
owned
by
roots
and
up
top
here.
So
this
is
within
the
container
and
we'll
be
able
to
see.
We
can
see
the
process
list
from
the
host,
so
you've
escaped
the
container.
We
can
also
see
this
tamp
file.
I
think
you
can
actually
see
that,
of
course,.
A
A
A
So,
just
to
recap,
we
can't
secure
a
thing.
We
know
there
are
problems
in
software
development.
Even
the
most
depended
upon
open
source
libraries
that
we
know
and
love
have
vulnerabilities
when
experts
working
on
them
and
humans
will
always
make
mistakes
that
will
always
generate
bugs.
We
know
there
are
problems
in
software.
Nothing
is
entirely
secure
and
the
cost
of
things
like
formal
specifications
for
all
code
is
too
high.
A
A
Only
with
sufficient
time
conformance
to
a
specification
does
not
guarantee
the
absence
of
exploitable
bugs
there's
quite
a
lot
here
and
probably
too
much
to
go
through
now,
but
nist
has
published
an
analysis
of
state
VR
on
how
to
reduce
software
vulnerabilities,
which
is
deeply
fascinating.
I'll
leave
these
in
here
posterity,
essentially
measure
software
quality,
use
good
teams
and
measure
the
cost
of
quality
of
what
you
do,
there's
also
wonderful,
secure
programming
how-to
by
David
wheeler.
This
is
all
free.
A
A
There
are
applicate
that
these
are
applicable
to
open
source
and
enterprise,
but
if
we
agree
that
humans
are
fallible
and
at
some
point
we'll
see
more
epic
open
source
failures,
there
must
be
something
we
can
do
to
prevent
ourselves
preemptively.
So
from
that,
let
Brazilian
architecture
is
the
one
that
stands
out
and
probably
the
one
of
most
interest
to
us
today.
So,
let's
examine
then
the
best
practices
with
a
view
to
so
we
know
these
are
the
things
containers.
A
good
app
is
security
which
into
this
list.
Well
the
integration
with
advanced
kernel,
security
features.
A
This
is
a
relatively
recent
addition
to
docker,
so
in
they
bad
at
security,
there
aren't
namespaces
for
everything
the
daemon
running
as
routes
age-old
criticism
which
is
changing
and,
of
course,
there
are
isolation,
trade
to
be
made
versus
a
hypervisor
there's.
Actually,
as
we
move
towards
things
like
hyper
SH
and
being
totally
containers
implementation,
then
those
docker
in
virtual
machine
implementations
are
keen
to
how
Google
Rome
these
containers
on
the
on
compute
engine
and
how
AWS
the
same
way
so
running
within
a
container
within
a
hypervisor
may
be
sort
of
the
best
of
both
worlds.
A
Ultimately,
as
he
said,
knowledge
mature
slightly,
but
a
good
thing
about
containers,
the
default
configuration
is
pretty
robust
at
this
point
and
at
any
review
who
are
in
that
security
talked
previously
with
Jess
Rizzo.
We
have
her
to
thank
for
a
lot
of
these
things.
The
reduction
of
dependencies
reduces
the
attack
surface
by
installing
minimal
tools
and
attaching
by
namespace,
rather
than
requiring
debugging
tools
to
be
built
into
the
application
units
were
shipping
fast.
A
The
software
updates
chain
of
trust
post-mortem
from
logging
drivers
so
that
this
is
a
list
of
all
some
of
the
vulnerabilities
the
containers
have
prevented
by
default.
It's
not
exhaustive
and
notably
unmitigated
are
the
kernel
issues
that
we've
been
through
previously.
So
how
does
docker
provide
security
hardening
again,
I'm
sure
everybody
knows
this.
We've
got
namespaces
providing
different
view
for
each
of
their
sub
components.
A
For
example,
the
pit
namespace
gives
different
process
IDs
inside
the
container
as
outside
the
container,
so
each
container
has
its
own
view
of
the
world
and
the
host
a
view
of
all
the
micro
vs.
with
Sider
got
Network
directories.
All
these
things
and
as
of
doctor
110,
we
also
have
user
name
spaces
which
are
in
their
first
implementation
at
the
moment,
because
the
curl
doesn't
quite
support
individual
user
names
bases
per
container.
That
will
change.
A
But
up
until
this
point
mapping
a
user
inside
the
container
to
non
brute
outside
the
container
is
the
best
mitigation
that
we
have
control
groups
again.
Preventing
processes
for
steaming
too
much
resource
and
doctor
runtime
configuration.
If
we
can
run
is
immutable
applications
with
unrideable
valves
root
file
systems.
Then
it's
helpful.
It's
not
up
again
a
panacea
because
you
can
just
type
the
loader
code
into
a
runtime
interpreter
for
this
one
there
or
execute
things
from
memory,
pit
limits
and
security
options,
especially
preventing
privileges
from
being
granted
after
the
container
started.
A
So
capabilities
allow
fine-grained
access
control
rather
than
just
I
am
routes.
The
Linux
kernel
has
over
600
system
calls
and
a
bug
in
any
one
of
those,
as
demonstrated,
can
lead
to
a
privilege
escalation.
So
this
reduces
the
chances
that
have
occasional
burn
abilities
are
exploitable
and
can
also
protect
us
from
dirty
cow,
which
we'll
go
through
and
demo
in
a
moment
that
have
relies
on
a
system
called
P
trace,
as
we
spoke
about,
which
has
a
legitimate
use
in
a
lot
of
cases.
A
For
example,
if
you
want
to
a
process
list
or
you
want
to
s,
trace,
attach
trace
to
a
running
process
or
invoke
a
process
that
way.
So
this
admins
need
this
tool,
but
in
this
case
it
was
exploited
and
we
can
run
through
how
to
prevent
it
from
being
available
with
inside
the
container
to
be
exploited.
A
A
A
Ships
gr
security,
extent,
colonel
and
also
doesn't
run
lib
sea
otter
doesn't
run
bash
by
default,
so
moving
applications
to
alpine
gives
you
a
large
amount
of
free
security.
Obviously
contending
with
running
news
all
versus
live
sea
is
something
that
may
be
dependent
upon
what
you're,
compiling
and
putting
into
your
containers.
In
the
first
place
system
policies,
insist
called
whitelisting.
These
allow
fine-grained
access,
control
to
system
calls
set
comp
is
the
most
comprehensive,
a
Parmen
SELinux,
our
Ubuntu
and
Red
Hat
specific,
and
that
Tamayo
is
its
own
sort
of
kernel
extensions.
A
A
A
A
busybox
container
to
the
network
namespace,
so
in
that
case,
once
you're
attached
to
the
network
namespace.
Of
course,
your
network
is
shared
with
the
container
that
you
attach
to
this
means
you
don't
need
to
install
TCP
dump
into
your
containers.
Essentially,
you
don't
need
any
debugging
tools
at
all.
You
can
bring
everything
with
you
and
attach
it
in
an
unprivileged
manner,
or
you
can
use
the
more
nucleus
Cystic
style
option
where
you
bring
a
privileged
container
in
and
you
operate
on.
A
The
hosts
view
of
the
system
depends
on
what
you
need
to
do,
ideally,
where
any
printed
containers
as
lost
resorts,
assisting
it's
a
wonderful
tool.
However,
avoiding
previous
antennas
where
possible
capability
drops,
are
essential.
These
namespaces
the
resource
limits
the
cgroups
afford
and
mounting
volumes
in
is
again
restricted
a
manner
as
is
possible,
so
we
can
also
use
things
like
notary
content.
Addressable
images
means
that
the
hash
that
we
see
for
dock
container
is
akin
to
get
a
Merkel
tree
related
to
the
contents
of
the
container
didn't
used
to
be
the
way
it
is
now.
A
We
can
use
those
as
cryptographic
security
to
make
sure
that
what
we
ship
from
our
development
laptops
makes
it
through
to
production
with
exactly
the
same
code.
Cube
lettuce
also
offers
some
security
controls
there,
either
at
the
pod
or
the
contain
a
level,
but
syntax
is
the
same
run
as
non-root
exploits
the
user.
Explorer
paint
the
wrong
word:
utilizes,
the
user
namespaces
that
we
spoke
of
before
single
username
space
to
run
the
user
in
the
container
at
non
routes
outside.
A
So
it's
only
on
the
dock,
a
demon
namespace,
but
this
will
change
with
the
next
iteration
of
kernel.
Namespace
implementation.
Fs
group
is
selinux
extent.
Sorry,
especially
it's
the
center's
volume
label
and
set
the
ownership
of
mounted
volumes
with
SS
groups
so
back
to
the
container
breakout.
And
let's
do
the
same
thing.
A
A
A
A
This
is
where
we
expect
to
see
a
similar
line
to
this,
an
app
armor
status
line
so
off
we
go
we're
making
the
same
tools
Emma
boys,
and
we
have
broken
straight
out
now.
Let's
just
have
a
look
at
what
we've
got.
Sorry
broken
up
the
top
term
with
the
application
there
we
go,
so
we
can
see
here
that
the
pete
ray
school
was
denied,
which
meant
that,
when
the
exploit
attempted
to
make
that
system
call,
the
app
are
Malay.
A
A
So
there
we
are
we've
locked
the
container
exploit
with
a
very
simple
change.
These
are
application,
specific,
there's,
no
one-size-fits-all,
and
there
are
some
tools
that
can
be
used
to
generate
profiles,
I'm
conscious
that
we've
almost
reached
the
end
of
time
with
quite
less
lunch.
I've
got
another
few
minutes
feel
free
to
reach
out
if
you're,
hungry,
otherwise
I'll,
try
and
whiz
through
the
rest
of
what
we've
got
here
so
auto-generated.
Second
profiles:
Jen
seconds
a
simple
way
around
this
Dhaka
slim
can
do
static
or
runtime
analysis
of
an
application
to
identify.
A
What's
this
calls
it's
made
and
then
generate
a
second
profile
based
on
that
and
Bain
is
again
courtesy
of
Jesse
cell
and
the
basis
of
an
app
armor
proposal
for
docker
core,
because
there's
no
one-size-fits-all
solution
and
restricting
too
many
system
calls
breaks
applications.
Then
this
is
pretty
complex
thing
to
get
right.
Finally,
the
we've
works
and
container
solutions.
Sock
shop
demo
is
shouting
ample
of
a
well
configured
kubernetes
manifest
this
goes
through
and
only
it
drops
all
privileges
and
only
re-enable
the
privileges
required
per
application.
A
So
there's
some
pipeline,
tooling
I'll,
run
through
briefly.
The
weakest
point
in
your
infrastructure
is
a
likely
a
circulation
point.
It's
a
leaky
secrets.
Prevention
again,
these
slides
be
published
swords
with
through
these
quickly
truffle
hog
searches
for
keys
by
looking
for
entropy
and
strings
good
for
finding
random
strings,
but
doesn't
find
AWS
access,
keys,
get
sequences
from
AWS
labs
if
finds
a
DRS
access
keys,
but
doesn't
search
for
broad
entropy
and
requires
a
lot
of
regex
configuration
so
insert
them
in
parallel,
probably
the
minimum
required
doc
container
scanning.
A
You
guys,
probably
know
most
of
these
pulling
vulnerabilities
from
the
NIST
vulnerability
database,
Claire
the
core
OS,
offering
lineThe
it's
more
or
less
open
source,
but
the
enterprise
doc
plugin
does
require
subscription.
Although
it
gets
a
shout
out
for
being
pure
c'mon
lion.
Beauty
docker
scan
is
a
new
tool
announced
at
root,
akan
Spain
that
essentially
tries
to
break
containers,
trojan
eyes
them
and
identify
which
user
is
actually
running,
which
is
more
complex
if
it
looks
really
interesting.
A
new
tool.
Looking
for
contributors
open
s,
cap
is
now
folded
into
Red,
Hat
stalling
as
well.
A
Banyon
collector
these
benders
all
do
the
container
scanning
an
IDs
worth
praising.
If
you
have
the
money
to
support
this,
if
you're
making
any
money
as
a
as
a
company
host
analysis,
doc
bench
is
sorry
host
knows
this
doc
bench
is
provided
by
docker
gives
you
a
checklist
of
the
things
that
you
should
or
shouldn't
be
doing
on
your
hosts
application
dependency
analysis.
We
want
to
make
sure
that
we're
not
bringing
vulnerable
versions
of
things
OpenSSL,
especially
been
so
last
nick-
will
actually
make
pull
requests
for
you.
A
So
you
get
an
automatic
routes,
remediation
of
vulnerabilities,
fuzzers,
american
fuzzy,
lop.
That's
what
it
looks
like
it's
an
amazing
tool
worth
just
playing
with
having
the
website
and
seeing
how
many
things
it
has
broken
web
application
scanners.
This
is
a
talk
in
itself,
but
these
can
go
in
the
pipeline
and
be
used
as
another
form
of
testing
running
somewhere
between
component
integration
and
system
acceptance
and
defined
behavior
of
applications.
I
should
have
a
client
search
on
here.
I
should
have
only
this
port
open,
etc.
A
So
how
do
we
stay
secure?
Well,
we
don't
make
our
houses
and
possessions
open
through
everybody.
We
look,
monitor
and
alarm
them,
and
this
is
referred
to
as
defense-in-depth
intrusion.
Detection
systems
are
a
necessary
part
of
this
should
always
run
them
in
production
and
anywhere
else
that
has
keys
to
production
and
can
be
escalated
from
which
contentiously
includes
build
servers
Fulco
consisting,
is
essentially
just
the
system
tracing
part
of
Cystic.
This
is
call
tracing
and
will
generate
alerts
for
you.
This
could
be
integrated
with
Cystic
cloud.
A
It's
all
open
source,
really
nifty
implementation,
there's
also
various
other
things
open
against
proprietary
entries,
snorts
being
the
old-school.
It's
all
about
the
future.
Nothing's
inherently
secure
open-source
software.
It
doesn't
really
matter
if
it's
secure
enough
secure
or
less
than
open
closed
source
secure
enough
for
our
needs,
as
endorsed
by
major
corporations
and
users.
But
this
talk
has
been
about
exploits
that
are
scary,
shiny
and
interesting,
but
they're
not
the
way
that
people
get
hacked
the
open
web
application.
Security
top-10
hasn't
changed
for
years
with
good
reason.
A
Application
vulnerabilities
at
this
level
are
the
easiest
routes
to
exfiltration
of
your
data.
Application
code
changes
far
more
frequently
than
the
infrastructure
code
that
we
put
beneath
it
so
prepare
for
the
unexpected,
secure
your
networks,
application
code,
Jesus
browsers
and
when
all
else
fails,
run
IDs,
so
there's
a
brief
set
of
recapping
points
and
our
perviously
slides
on
twitter
afterwards.
Thank
you.