►
From YouTube: Exploiting a Slightly Peculiar Volume C... Ian Coldwater, Brad Geesaman & Rory McCune, Duffie Cooley
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Exploiting a Slightly Peculiar Volume Configuration with SIG-Honk - Ian Coldwater, Twilio; Brad Geesaman & Rory McCune, Aqua Security; Duffie Cooley, Isovalent
When the hacker crew of geese collectively known as “SIG-Honk” read about a new CVE in the Kubernetes ecosystem affecting the runc project (CVE-2021-30465), they flew into action. With just a few details in the initial advisory notes as guidance, they were able to collaborate and generate a proof-of-concept exploit for Kubernetes, iterate and validate it against multiple types of clusters, and kick off a renewed coordinated disclosure process to help keep users safer. Join Ian Coldwater, Brad Geesaman, Rory McCune, and Duffie Cooley as we bring our expertise and experiences to share the details of our methodology, walk through our approach, and demonstrate the exploit and its effectiveness live on stage. Attendees will learn about the process of exploit development and disclosure, find out how to stay informed about vulnerabilities in open source dependencies that may affect the security of their clusters, and walk away with a new perspective on how to honk.
A
Hi
everybody
welcome
to
kubecon
north
america,
2021
we're
sig
honk,
a
hacker
crew,
not
an
official
kubernetes
cig
and
we're
here
to
present
a
story
for
you
about
how
we
came
across
a
runcie
vulnerability
advisory.
We
flocked
together
to
understand
it
developed
a
proof
of
concept
for
kubernetes
for
it
and
shared
our
findings
with
the
world.
We
are
excited
to
get
to
share
them
with
you.
B
Hey
everybody,
I'm
duffy
cooley
and
I
can
be
found
everywhere
as
maui
lyon.
I
host
this
week
on
cloud
native
on
cloud
native
tv
and
ebpf
office
hours
on
youtube.
One
of
the
big
takeaways
of
this
talk
for
me
is
that
we
all
level
each
other
up.
It
takes
a
village
to
move
a
project
like
kubernetes
forward,
whether
from
the
security
perspective,
writing
and
reviewing
code
documentation
or
in
the
day-to-day
release
efforts.
There
are
so
many
ways
to
get
involved
find
the
part
that
inspires
you
and
jump
in
everyone
is
welcome.
C
C
Also
when
you're
examining
a
vulnerability,
this
complexity
shows
up
as
well.
So
if
you're
trying
to
prove
a
kubernetes
vulnerability,
one
question
is
well
which
kubernetes
distributions
does
this
affect
there's
well
over
a
hundred
choices
to
test
and
if
a
vulnerability
affects
all
of
them,
or
even
just
the
most
used
ones,
it
can
be
a
lot
of
work.
D
A
Hi,
I'm
ian
coldwater,
I'm
co-chair
of
kubernetes
security
security
in
the
cloud
native
ecosystem
is
complex.
Every
container
system
is
only
as
secure
as
every
part
of
its
stack.
Everything
is
connected
in
the
dependency
chain,
but
different
projects
are
responsible
for
different
parts.
Sometimes
it
can
be
hard
to
know
who
exactly
is
responsible
for
what,
especially
when
things
connect
with
multiple
projects.
How
do
we
solve
this
like
our
dependencies?
We
connect
and
depend
on
each
other.
A
We
all
take
responsibility
for
the
security
of
the
ecosystem
when
we
bring
our
different
skills
and
perspectives
to
the
ecosystem
as
a
whole.
We
can
see
things
we
might
not
have
spotted
by
ourselves
when
we
work
together
as
a
community
we
get
farther
than
we
would
if
we
were
working
on
our
own.
This
story
is
one
example
of
how
it
can
look
when
different
groups
of
people
work
together,
like
that
now,
let's
get
into
the
timeline.
C
This
story
starts
in
one
of
those
places
with
a
message
that
was
sent
to
the
sig
security
channel
in
slack
about
a
vulnerability
in
the
run
c
project
originally
found
by
etienne
champatie
cve,
2021,
30465
vulnerabilities
in
run
c
are
especially
interesting
as
as
a
key
role
in
the
container
ecosystem.
It's
the
tool
that
actually
launches
containers
and
is
used
as
part
of
many
other
projects
like
docker,
container
d
and
cryo.
C
Also
most
cluster
operators
will
never
actually
install
runc
directly
and
may
not
even
realize
they
have
it
installed.
After
looking
at
the
advisory,
I
had
a
quick
look
at
the
releases
for
projects
that
bundle
run
c
and
noticed
that
both
docker
and
cryo
were
yet
to
release
a
patched
version.
Although
container
d
had
this
was
pretty
interesting
to
me,
because
it
meant
that
a
large
proportion
of
clusters
were
possibly
still
exposed
to
the
issue.
D
There
was
no
proof
of
concept
code
included
in
the
original
advisory,
but
there
was
enough
detail
to
understand
that
it
was
likely
a
widely
applicable
container
escape.
The
write-up
mentions
kubernetes
and
volume
mounts
as
the
point
of
attack,
but
it's
not
clear
exactly
how.
So
I
asked
the
group
if
we
should
try
to
recreate
a
poc
ourselves.
A
And
I
said,
be
the
change
we
wish
to
see.
Each
of
us
brought
us
brought
our
own
perspectives
to
this
brad
wanted
to
know
how
it
worked.
I
wanted
to
break
it
for
fun
and
rory
reminded
us
that
we
needed
to
raise
awareness
and
figure
out
mitigations
so
that
we
could
communicate
better
out
to
end
users
and
duffy
brought
us
together
and
herded
all
the
cats.
B
So
the
first
thing
so
first,
I
was
really
surprised
by
this
one.
I
thought
this
was
a
very
interesting
cbe
and
the
first
thing
I
did
was
create
a
hackmd
and
start
gathering
details,
and
so
I
pulled
in
the
text
from
the
cbd
patch
notes.
I
pulled
in
the
text
from
the
advisory
and
then
I
started
throwing
up
a
couple
of
theories
about
how
this
would
work.
This
document
that
I'm
talking
about
is
a
shared
document
and
it
will
be
a
part
of
the
resources
at
the
end
of
this
presentation.
B
I
was
also
thinking
about
how
we
could
quickly
iterate
on
something
like
this,
because
we
needed
an
environment
that
all
of
us
had
access
to
that
we
could
start
playing
with
this
and
iterating
on
these
things.
For
that
environment
we
chose
to
use
kind
kind,
is
a
a
sub-project
of
kubernetes
and
you
can
check
it
out
at
kind
dot.
Sigs
dot
k
is
to
io.
It's
used
to
actually
test
a
lot
of
the
kubernetes
code
on
pull
requests,
and
it's
also
used
to
create
lightweight
kubernetes
clusters
in
docker
and
inside
of
each
of
the
nodes.
B
C
So
offering
a
great
source
of
information
about
exploits
for
vulnerabilities
is
the
blog
posts
of
people
who
discovered
them.
So
with
that
in
mind,
I
went
to
see
if
etienne
had
a
post
detailing
how
he'd
found
this
issue
after
finding
there
wasn't
anything
up.
Yet,
although
there
were
a
lot
of
other
great
write-ups
on
his
blog,
I
decided
to
drop
etienne
a
cold
email
to
see.
If
there's
anything
more,
he
could
tell
us
he
very
kindly
responded
quickly
and
provided
some
useful,
high-level
information
about
how
he'd
exploited
it,
but
not
the
full
technical
details.
A
While
duffy
was
looking
at
the
tests
in
the
source
code
for
that
run
c
patch
release,
I
was
reading
the
patch
notes
on
that
fix,
which
were
different
from
the
notes
on
the
advisory.
These
notes
went
into
more
detail
describing
an
order
of
operations
for
the
attack,
which
gave
us
more
insight
as
to
how
this
exploit
might
work.
The
notes
also
called
out
that
they
thought
it
was
an
incomplete
fix
that
they
thought
there
was
probably
more
attack
surface
lurking
there
specifically
involving
mount
targets.
That's
always
fun
to
read
what
were
they?
D
We
started
framing
up
what
it
would
look
like
to
exploit
this.
We
knew
it
could
be
exploited
with
an
empty
dirt
volume
based
on
the
information
that
rory
had
learned
from
etienne.
It's
a
big
clue,
knowing
that
it
had
to
be
leveraging
a
tactile,
a
time
of
check
time
of
use
attack.
We
knew
the
what
and
the
where,
but
we
still
needed
to
figure
out
the
how.
B
All
of
us
were
definitely
out
of
our
comfort
zone
a
bit
when
trying
to
piece
a
vulnerability
like
this
together
enough
to
build
an
exploit.
It's
important
that
you
don't
get
discouraged.
If
this
takes
you
out
of
your
comfort
zone,
that's
when
you
grow
the
most.
This
stuff
is
complex.
Just
keep
trying
things,
as
you
will
see
in
the
demonstration.
It's
kind
of
amazing
that
this
stuff
is
found
at
all.
A
A
We
definitely
didn't
all
understand
it
from
the
advisory.
I
tried
to
explain
the
order
I
understood
from
it.
I
kind
of
ended
up
sounding
like
conspiracy,
charlie,
in
that
meme
brad
was
like.
I
don't
know
about
this.
I'm
just
gonna
go,
try
poke
at
it
fair
enough,
I'm
glad
he
did
because
at
the
end
of
the
day,
I
think
it
worked
out
better.
That
way.
If
I
had
done
it,
I
would
have
just
ended
up
replicating
the
original
poc
brad's
differing
approach
got
different
results
and
I
think
better
ones.
A
I
didn't
know
about
this
one.
I
love
the
folks
on
the
src.
My
best
friend,
tabby
sable
is
on
the
src,
but
in
this
particular
case
I
was
not
at
all
sure
this
was
the
right
call,
because,
while
I
understood
that
the
src
can't
be
responsible
for
all
advisories
in
all
third-party
dependencies,
there
are
in
fact
a
lot
of
them.
This
one
in
particular,
said
in
the
advisory
that
it
would
be
easiest
to
leverage
from
within
a
kubernetes
environment.
A
It
called
us
out
specifically,
and
so
whether
or
not
this
one
was
technically
our
problem,
it
had
become
our
problem.
What
did
this
thing
do
in
a
kubernetes
environment
we
weren't
really
quite
sure
yet,
but
clearly
it
did
something.
We
wanted
to
figure
out
how
it
worked
and
make
sure
end.
Users
would
have
the
information
that
they
needed
to
know
how
to
mitigate
it.
D
From
the
information
we
had,
my
theory
was,
it
could
be
a
lot
like
the
subpath
sim
link
race
approach
from
a
2017
cve.
So
I
wanted
to
give
that
approach
a
shot
and
share
the
feedback
with
the
group.
My
hypothesis
was,
it
could
be
as
simple
as
a
single
pod,
with
two
containers
sharing
two
volumes.
The
first
container
starts
and
immediately
goes
into
a
never-ending
loop,
replacing
a
specific
folder
with
a
sim
link
to
root.
D
I
initially
made
this
deployment
with
20
replicas,
I
even
tried
50
or
100,
but
20
seemed
reasonable
as
a
balance
to
increase
those
the
number
of
chances
of
winning
after
a
lot
of
failed,
runs
and
frustration
of
not
seeing
anything
mounted
in
that
second
volume
path,
I
got
lucky
at
one
point.
I
just
happened
to
run
a
loop
of
kubecontrol
execs
to
list
the
root
directory
of
all
the
pods
file
systems,
as
it
quickly
scrolled
by.
D
I
just
happened
to
notice
that
one
of
them
had
fewer
directories
and
all
the
rest
and
closer
inspection
revealed
that
one
of
them
had
the
slash
kind
directory.
I
remember
thinking
why,
like
after
executing
in
and
poking
around,
I
realized
the
containers
root
was
mounted
from
the
nodes
root
file
system,
which
was
completely
unexpected.
A
This
makes
sense
because
race
conditions
are
a
notorious
pain
to
exploit
they're
finicky
and
they
take
a
long
time.
You
don't
always
get
them.
You
have
to
keep
trying
and
you
have
to
wait.
Sometimes
it
can
be
hard
to
tell
if
you
even
won
the
race
successfully
and
then,
when
you
have
to
do
it
again,
they
can
be
hard
to
reproduce.
D
Yeah,
it
was
quite
irritating
knowing
that
the
race
could
be
won,
but
reliability
was
still
elusive,
but
a
big
reason
for
that
was
it
didn't
behave
at
all.
How
we
originally
thought.
So.
The
first
thing
I
wanted
to
do
was
share
the
fun
and
make
sure
that
everyone
else
could
replicate.
So
I
updated
the
hackmd
with
the
smallest
possible
working
manifest
and
a
little
bit
of
instructions.
C
So
what
we
had
here
was
a
talk
to
vulnerability.
Now,
a
talk
to
vulnerability
is
a
class
of
software
bug
caused
by
a
race
condition
involving
the
checking
of
the
state
of
a
part
of
a
system
such
as,
in
this
case,
sanitizing,
a
path
and
the
use
of
the
results
of
that
check.
What
exactly
does
that
mean
here?
Well,
there
is
a
check
which
happens
during
the
container
startup
when
volumes
are
mounted
into
that
container
to
ensure
that
the
file
system
path
is
one
which
is
allowed
to
be
there.
B
You
can
actually
get
as
a
single
endpoint,
so
what
we
decided
to
do
was
create
a
daemon
set
that
would
cache
our
image,
the
nginx
stable
image
on
all
nodes,
and
then
we
would
wait
for
that
daemon
set
to
land
and
be
successful
before
deploying
a
the
deployment.
The
deployment
actually
holds.
The
holds
the
bits
that
we're
going
to
use
to
actually
try
and
recreate
this
tactile
attack.
B
B
So,
where
we're
just
constantly
deleting
a
file
if
it
caught,
if
it
exists,
called
host
and
and
then
sim
linking
the
root
file
system
over
that
file
right
and
so
the
intention
is
that,
if
we're
successful,
then
we
we
should
be
able
to
see
that
we
file
system
but
we'll
see
how
it
shakes
out.
The
subsequent
containers
are
named
one
honk,
two
honk
three
hunk,
and
these
containers
are
basically
mounting
up
and
sleeping
forever.
B
They
mount
that
honk
volume
and
then
they
mount
another
another
volume
on
top
of
that
and
empty
their
volume
called
host,
and
this
is
the
thing
that
we're
deleting
and
overwriting
with
that
sim
link,
and
so
the
timing
attack
is
exactly
that.
We're
just
trying
to
you
know
for
every
for
these
three
containers
and
every
one
of
the
replicas.
That's
part
of
this
deployment
we're
going
to
be
trying
to
get
that,
and
here
is
the
logic
of
the
script
here
right.
So
what
we're
doing
is
we
do
a?
B
We
pull
a
list
of
all
of
the
running
pods
that
are
not
in
a
terminated
state.
We
sort
them
by
creation
timestamp,
and
then
we
iterate
through
them
doing
this
check,
and
this
was
probably
this
is
the
most
portable
way
that
we
could
figure
out
how
to
do
this
because
it
would
work
regardless
of
whether
you
were
using
coming
in
as
root
or
as
a
user,
and
what
it's
doing
is
we're
executing
into
that
pod.
B
D
D
B
D
C
D
So,
oh
nice,
all
right,
I'm
just
going
to
run
this
cube,
control,
exec
and
we're
going
to
exec
into
this
pod.
What
I
want
to
show
you
is
that
if
we
run
a
hostname
we're
still
inside
the
pod,
we're
still
inside
the
container,
so
we're
not
quite
there.
Yet
it's
a
little
bit
weird
I'll,
explain
that
why
why
that
is
in
a
second
we're
in
the
containers
network
namespace.
D
D
We
actually
can't
kill
it
because
we're
not
in
the
host's
process
name
space,
although
we
are
root,
but
because,
because
of
that,
it
doesn't
really
mean
we're
fully
limited.
We
have
root
access
to
the
file
system,
read
write
access
to
the
file
system.
There
are
plenty
of
things
that
we
can
do.
One
of
the
things
that
we
can
do
because
we
know
we're
in
a
kubernetes
cluster,
is
leverage
the
secrets
that
are
attached
to
the.
Let
me
let
me
scroll
back
up,
so
you
can
see
that
command.
D
We
could
do
a
find
here
and
we
can
look
at
all
the
tokens
and
the
secrets
that
are
mounted
to
pods
running
on
this
node.
So
we
could
do
this.
You
know
multiple
times
across
multiple
nodes
and
attempt
to
steal
all
the
tokens
in
the
cluster.
So
that's
that
that's
pretty
dangerous.
You
might
have
a
cluster
admin
bound
token
there
in
the
first
go.
D
D
If
you're
a
pen
tester-
and
you
want
to
leave
a
backdoor
access,
you
could
add
yourself
to
the
root's
authorized
keys
and
get
in
that
way.
That's
a
nice
one,
quick
one,
but
also
we
know
that
we're
running
potentially
docker.
If
this
command
succeeds,
yup
we
have
access
to
the
docker
socket,
so
we're
just
one
step
away
from
being
able
to
get
full
access
to
the
node.
D
And
what
do
I
mean
by
full
access
to
the
node,
I'm
going
to
run
a
utility
called
mi
contained
written
originally
by
jess
frisell,
and
we
could
see
here
that
we
have
some
capabilities,
but
we
have
several
block
syscalls.
So
this
is
enumerating
what
access
I
have
am
I
contained
yes,
I'm
running
in
docker,
but
what
what
sys
calls
do?
I
have
what
are
potentially
blocked.
B
D
Like
I
said,
we're
one
command
away
via
a
docker
run,
so
let
me
paste
this
in
so
we're
going
to
run
a
privileged
container
in
the
host's
network,
name
space,
the
hostpid
namespace
we're
going
to
mount
the
root
volume
again,
but
inside
the
this
container
as
host,
but
then
we're
going
to
root
right
into
it
and
run
a
bash
shell.
So
this
is
effectively
like
give
me
the
full
access
please
now,
when
we
run
hostname,
we
can
see
yep,
it's
minicube.
D
D
Am
I
contained
okay,
this
time?
Yes,
we
technically
are
running
inside
of
docker,
but
we
have
full
capabilities.
We
have
cisad
and
then
you
know
all
the
other
things
that
we
need
to
do
the
damage,
and
so
that
proves
here
that
you
know
we
have
the
ability
to
leverage
this
to
make
a
full
node
takeover.
A
This
was
wild
and,
frankly,
really
alarming
to
us,
because
this
exploit,
as
it
appears
in
our
poc,
appears
to
give
the
exploited
pod,
read,
write
access
to
the
host
file
system
and
a
view
of
the
hostpit
namespace.
It's
not
a
complete
view.
We
can't
kill
processes
directly,
but
we
could
harvest
environment
variables
and
interact
with
the
root
file
system
as
the
root
user.
In
the
demo
we
leveraged
that
access
of
the
docker
socket
to
get
us
to
full
root.
We
also
learned
during
testing
that
this
exploit
is
still
successful.
A
I
mentioned
to
my
co-chair
tabby
sable
what
we
were
up
to
who
got
curious,
as
we
saw
in
the
demo.
We
have
the
root
s
fs
and
the
pid
namespace
and
tabby
wanted
to
know
what
was
up
with
the
pid
namespace,
so
tabby
reached
out
to
duffy
with
technical
questions,
and
they
dug
in
a
bit
in
a
side
exploration.
B
Yeah,
that
was
a
that
was
a
fun
chat
with
tabby.
We,
we
spent
some
time
like
trying
to
dig
through
and
understand
like
what
name
spaces
we're
a
part
of
and
like
what
name
spaces
we
weren't
a
part
of
and
really
it.
It
seems
at
the
end
of
the
day,
to
be
quite
simple
right
like
that.
That
attack
that
we
saw
in
the
deployment
and
also
that
we've
covered
a
couple
of
different
times.
B
It's
a
binary
running
in
the
root
file
system
of
the
underlying
node
and
when
you
said
to
make
a
sim
link
of
the
root
file
system
into
that
volume,
that's
exactly
what
it
did
and
it,
and
so
the
interesting
part
is
like
when
you
do
ps
minus
cf.
You
see
all
those
pids
but
you're,
really
just
reading
from
the
file
system
mount
of
proc.
It's
like
process
mounted
over
your
file
system,
it's
not
the
pid
namespace,
which
is
why
we
can't
kill
processes.
D
In
etienne's
approach,
it
leveraged
a
small
binary
to
do
the
sim
link
swapping
so
a
custom
image
was
needed,
but
it
tended
to
win
the
race
a
bit
quicker.
It
meant
you
could
mount
an
arbitrary
path
from
the
node's
file
system
inside
the
container
in
a
sub
directory.
In
our
approach,
the
manifest
itself
was
a
lot
simpler,
as
we
just
used
bash
to
do.
The
sim
link
swapping,
but
we
ended
up
with
the
node's
root
file
system
mounted.
D
As
the
containers,
ours
tends
to
take
a
bit
longer
to
win
the
race,
but
the
manifest
was
crafted
in
such
a
way
that
it
didn't
require
a
custom
image.
I
mean
we
used
nginx
stable,
but
it
could
be
any
other
base
image
that
had
the
base
linux
utilities
in
it,
and
it
would
be
accepted
by
mission
control
aside
from
running
as
the
root
user,
to
make
that
quick
path
to
root.
C
Yeah,
so
we
tested
this
on
various
clouds
and
distributions
to
see
what
had
or
had
not
been
patched
breaking
it
down
and
dividing
up
the
work
amongst
all
of
us.
One
unusual
thing
we
did
notice
during
testing
is
that,
despite
having
a
run
c
version
which
should
have
been
affected,
we
couldn't
get
the
exploit
to
work
using
amazon's
eks
distribution
with
the
latest
ami.
C
This
provoked
a
bit
of
head
scratching,
but
doing
some
research
into
the
error
messages.
We
were
getting
and
also
reading
etienne's
original
disclosure,
which
we'd
received
by
that
time,
led
us
to
realize
that
amazon
had
put
in
a
mitigation
in
place
by
back
porting
the
security
fix
without
updating
the
run
c
version
number
in
general.
This
is
something
you
need
to
watch
for
when
you're
doing
vulnerability,
research
and
assessment
as
back
porting
security
patches
is
a
technique
used
by
quite
a
few
vendors.
A
It's
also
something
you
might
want
to
watch
out
for,
if
you're
trying
to
figure
out
if
you've
mitigated
as
an
end
user,
because
the
version
number
might
not
actually
tell
you
for
sure
sure.
So
when
we
were
testing
these
things,
we
used
the
scientific
method.
We
broke
down
the
different
cloud
providers,
different
versions
of
things
they
were
running
and
we
tried
them
all
to
see
if
our
hypothesis
held
and
what
we
found
was
that
a
lot
of
large
clouds
were
vulnerable.
A
A
lot
of
default,
installs
of
major
cloud
provider
services
were
exploitable
and
we
realized
that
this
problem
was
really
quite
widespread
and
likely
a
lot
of
cluster
operators
and
end
users
were
going
to
be
at
risk.
So
to
reiterate,
we
knew
this
exploit
was
a
complete
node
takeover.
We
knew
it
even
could
be
when
you
weren't
running
that
container
as
root,
and
we
knew
that
it
wasn't
patched
in
a
lot
of
places.
A
This
was
concerning,
while
we
still
weren't
quite
sure
why
this
exploit
worked
the
way
it
did,
it
was
clear
that
it
did
and
it
was
bigger
and
nastier.
We
thought,
then
maybe
we
or
maybe
even
other
people
had
originally
thought.
I
was
growing
increasingly
concerned
about
this
about
the
impact
this
thing
might
have
how
many
people
might
be
at
risk
for
it,
and
the
response
so
far
had
been
honestly
far
more
nonchalant
than
I
thought
it
needed
to
be.
A
A
We
needed
to
be
the
ones
to
help
bring
more
information
to
users
and
to
the
ecosystem.
As
I
said
earlier,
be
the
change
we
wish
to
see.
So
we
reached
out
and
disclosed
this
to
the
kubernetes
security
response
to
committee,
expressing
that
we
thought
this
vulnerability,
scope
might
be
bigger
than
we
had
originally
thought
and
that
we
thought
maybe
more
of
a
response
might
be
needed
and
the
src
actually
responded
really
well.
A
They
responded
right
away,
understanding
our
concerns
and
encouraged
us
to
write
a
blog
post
on
the
kubernetes
blog
about
it
here
toward
end
users
with
mitigation
advice.
We
did
write
this,
but
it
took
a
while
to
get
published
because,
as
it
turns
out
that
work
around
this
vulnerability
ended
up
being
ongoing.
A
So
the
src,
also
besides
talking
to
us
about
that
talk
amongst
themselves
and
a
group
of
people
from
google,
then
went
and
continued
this
work
looking
into
this
vulnerability,
and
why
exactly?
It
was
doing
this
thing.
It
was
doing
so
they
continued
the
research
and
building
upon
our
work.
They
found
more
looking
at
our
work,
leveraging
subpath
mounts,
they
continued
going
down
that
path
and
what
they
ended
up.
Finding
was
a
completely
new
cve,
which
was
a
vulnerability
in
the
kublet
cve
2021-25741.
A
A
We
think
that
there's
a
lot
to
be
learned
from
this
story.
We
think
that
we
all
if
we
work
together,
can
level
each
other
up
at
the
end
of
the
day.
This
talk
is
about
working
together,
coming
together
as
a
community
and
building
upon
each
other's
work,
so
that
we
can
figure
out
more
find
more
that's
going
on
bring
better
information
to
end
users
and
make
the
ecosystem
as
a
whole
more
secure.
C
D
We
got
a
little
bit
lucky
sure,
but
without
that
level
of
effective
collaboration,
I
could
easily
imagine
a
scenario
where
we
didn't
overcome
the
confusing
or
frustrating
parts,
and
there
were
plenty
of
those.
And
lastly,
knowing
that
this
team
effort
raised
more
awareness
of
the
vulnerability
and
helped
the
main
goal
of
getting
vendors
to
release
patches
to
end
users
quicker.
I
think
that
brings
us
all
a
lot
of
satisfaction.
B
All
of
us
played
a
part
in
this
and
it
was
really
fun
to
explore
an
interesting
new
talk
together.
Here
is
a
slide
with
reference
material,
and
it
will
take
you
to
the
links
for
the
same
link
script
that
we
wrote.
The
wrote
it'll
take
you
to
our
hackmd
notes
that
we
originally
gathered
context
with
and
it'll
also
show
you
the
the
cbe
documentation
for
a
couple
of
the
both
etiennes
and
also
the
one
that
ian
referred
to.