►
Description
Securing Fluent Bit by Way of Fuzzing - David Korczynski, Ada Logics
This talk will cover efforts in automating security and reliability analysis of Fluent Bit by way of fuzzing. Fuzzing is an automated testing technique that is used in combination with bug sanitizers to identify code issues in software. In the last two years David has set up extensive continuous fuzzing of Fluent Bit by way of the open source fuzzing service OSS-Fuzz, and in this talk David will present details of this work and the results achieved, and also highlight how this impacts the overall security of Fluent Bit. The talk will cover the implementation of automated testing, the bugs found and various related statistics. The talk will relate the efforts in automated security testing onto how it impacts the security posture of Fluent Bit at large.
A
So
in
brief,
how
many
he
has
heard
about
fussing
before
no
one?
Oh
one,
I
think
there
was
two
two
people,
three
people
how
how
it
keeps
going.
Okay,
so
essentially,
fussing
is
a
way
to
automate
test
case
generation
and
test
case
generation
in
this
sentence
means
input
to
kind
of
like
a
proxy
test
that
will
explore
code
coverage
in
many
different
ways,
and
the
idea
here
is
that
fluent
bit
is
written
in
c,
which
makes
it
susceptible
to
memory.
A
Corruption,
issues
and
the
problem
at
hand
that
I
will
be
talking
about
in
this
case
is
how
we
can
use
fussing
to
generate
test
cases
for
fluent
bit
and
then
find
bugs
in
that
way,
and
in
short,
the
solution
is
to
implement
a
lot
of
fusses
and
running
them
continuously,
with
a
project
called
oss.
First,
that
I
will
also
get
in
depth
with
in
this
talk.
So
this
talk
is
about
essentially
finding
bugs
in
fluent
bit
using
various
automatic
test
case
generation
approaches
and,
in
this
case
fussing.
A
So
in
short,
it
is.
This
talk
is
about
fussing
fluent
bit
to
find
bugs
continuously
with
oss
first,
and
the
idea
here
is
not
just
we're
not
just
looking
to
find
bugs
for
the
sake
of
finding
bugs,
but
the
idea
is,
if
you
keep
finding
bugs
eventually,
you
will
stop
finding
bugs,
because
you
have
found
all
the
bugs
that
are
present
so
fasting
introduction.
A
Fussing
is
essentially
a
way
to
generalize
unit
tests
in
many
ways.
This
is
certainly
not
the
whole
truth,
but
I
think
that
this
is
the
way
we
have
done
it
for
for
fluent
bit
and
on
the
left.
You
have
an
example
of
if
you
were
to
test
api
with
many
different
inputs,
you
would
just
have
a
sequential
set
of
statements.
A
Testing
the
given
api
with
input,
one
input,
two
input
three
and
so
on,
and
the
way
you
would
kind
of
extrapolate
this
into
a
fossa
is
to
have
a
loop
that
calls
into
my
api
and
then,
instead
of
using
fixed
inputs,
you
will
just
ask
the
first
give
me
some
input
and
there
is
then
a
lot
of
underlying
technologies.
That
means
the
input
the
foster
will
give
you
this
kind
of
reason
about
it,
come
up
with
in
a
semi-random
way.
A
A
The
truth
is
that
fussing
did
start
as
random
testing.
That's
how
it
started
30
years
ago.
But
since
then
there
has
been
a
lot
of
academic
work,
a
lot
of
practitioners
and
so
on.
Really
trying
to
optimize
this
strategy
or
this
technique
and
modern
days
fosters,
are
not
really
random.
Testers
anymore,
it's
more
accurate
to
call
them
generic
genetic
mutational
algorithms.
A
So
it's
essentially
ways
to,
and
also
here
it
should
say
that
modern
days,
fusses
refer
to
coverage,
guided
forces
and
there
are
hundreds
of
academic
papers
on
how
to
improve
fussing
in
the
last
decade
or
so
so
this
just
a
little
heads
up.
If,
if
you
have
this
kind
of
view
or
have
heard
that
it's
random
testing,
it's
a
lot
more
than
that
as
well,
and
I'm
going
to
try
and
argue
a
little
bit
about
this.
So
the
way
a
faucet
works
is
that
it
has
this
corpus
set.
A
A
A
A
For
example,
if
you
have
this
symbol
c
program
on
the
right
composed
of
four,
if
statements
it
has,
it
will
check
the
first
four
bytes
of
a
given
buffer
if
they're
equal
to
a
b
c
d,
and
if
we
just
were
to
do
random
testing,
we
essentially
had
one
in
two
to
32
chance
of
guessing
this
right,
because
we
would
have
to
guess
four
buffers,
sorry
for
four
bytes,
which
is
32
bits,
but
in
code
coverage,
sorry
using
fussing
code
coverage
coverage,
guided
fussing.
Sorry
this
will
be
reduced
to
two
lifted
to
the
eight.
A
So
we
have
to
guess
each
byte
one
at
the
time,
which
will
be
one
and
two
to
the
56
chance
of
guessing
each
byte
times
four.
So
let
me
show
you
what
this
means
in
practice.
So
at
the
first
we
start
with
no
seed
and
we
have
to
just
guess
the
first
byte.
Okay,
we
have
a
one
out
of
256
chance
of
guessing
it
right.
A
A
Fussing
requires
a
lot
of
management
because
we
need
to
save
the
core
bus
we
need
to
like
keep
track
of
all
the
box.
We
need
to
make
sure
whether
box
are
found
are
reported
and
all
this
stuff,
and
this
takes
a
a
lot
of
management
to
do
so
when
we,
when
we
integrated
fasting
into
fluent
bit,
we
need
we
needed
to
have
some
way
of
doing
this
at
a
infrastructure
level,
rather
than
just
running
our
fusses
a
little
bit
every
monday,
or
so.
A
Some
false
concepts:
okay
and
so
google
will
take
care
of
building
and
running
the
fossils
reporting
when
bugs
are
found
verifying
when
fixes
are
found.
So
whenever
we
get
a
bug
in
fluid
bit,
we
get
like
a
stack
trace,
reducing
input
and
what
we
will
then
do
is
we
will
fix
the
bug
on
the
fluid
side,
and
then
google
will
also
verify
it
for
us
that
our
bugs
have
been
found.
A
So
in
terms
of
fuzzing
fluent
bit
the
workflow
the
whole
kind
of
like
procedure
that
we
have
had
over
the
last
two
years,
approximately
the
first
step
was
to
integrate
fluent
bit
into
oss.
First
implement
a
bunch
of
fusses
that
hit
the
fluent
bit
code.
Then
allow
oss
first
to
run
this.
These
fosters
for
a
while.
Then
we
would
see
bugs
start
to
appear.
A
So
here's
an
example
of
a
faster
for
the
fluency
code.
It's
essentially
all
of
the
fusses
that
we
have
written
are
very
similar
to
the
unit
tests
that
you
will
find
in
the
fluent
bit
repository,
and
you
can
see
that.
So.
This
is
the
full
source
code
of
the
code
by
the
way,
and
this
will
essentially
explore
all
of
the
code
inside
of
the
flb
serpee
time
function.
So
we
take
the
data
given
to
us
by
the
fossa,
which
is
this
argument
up
here.
A
We
then
convert
this
data
into
two
null
terminated
strings,
because
it
will
just
be
a
complete
binary
blob.
The
data
that
we
originally
get
and
fluent
bit
functions
use
null
terminated
strings,
so
we
kind
of
have
to
wrap
it
into
data
that
that
fluent
bit
understands
and
then
it
will
call
into
the
serpee
time
function.
A
You
can
see
the
link
here
to
the
fuzzer.
Another
example
is
a
phosphate.
We
have
for
the
json
passing
logic
in
fluent
bit
and
again,
it's
a
very
small
stop
10
lines
of
code
where
essentially,
only
two
of
the
lines
are
the
important
ones.
We
create
a
parser,
and
in
this
case
it's
a
json
parser,
and
then
we
and
then
we
simply
pass
the
data
data
and
size
here
that
is
given
to
us
by
the
fossa.
A
We
simply
like
use
that
as
input
to
the
passing
routines-
and
this
will
explore
almost
all-
I
believe-
of
the
code
under
the
in
the
flb
underscore
pass
underscore
dual
routine
there,
a
few
caveats
of
some
code.
It
won't
be
exploring
I'll
get
into
that
later,
but
those
are
like
the
small
stops
that
we
write
in
order
to
fuss
the
fluent
big
code,
so
very
simple,
very
much
like
unit
tests.
The
only
difference
is
that
we
don't
have
specific
data
here.
A
We
kind
of
have
data
provided
by
the
fossil,
so
all
of
this
code
is
available.
All
of
the
fusses
for
bit
are
available
in
test
slash
internal
slash,
fossus
and
there's
also
a
pdf
report
in
the
film
bit
repository
I
think,
from
a
year
ago,
or
so,
where
we
document
a
lot
of
the
findings
at
that
stage
and
the
the
fuzzes
that
we
wrote
and
the
focus
so
far
in
terms
of
forcing
fluid
has
been
on
first
of
the
code
in
the
src
repository.
A
So
the
code
coverage
has
visualized
achieved
by
the
current
first.
I
think
that
there
are
around
15
verses
and
the
code
coverage
we
have
so
far
is
just
about
40
44
of
the
code
in
src,
and
this
is
you
can
see
it's
like
a
snippet
of
some
of
the
code
here.
That
is
being
like
the
some
of
the
the
the
functions.
Sorry,
the
files
that
are
being
targeted
and
you
can
see,
for
example,
the
this
pick
one
file.
Let's
say
the
flb
underscore
parser.
A
So
what
are
the
results
that
we
have
got
so
far
and
the
results
in
this
case
so
I
have
shown
essentially
the
code
coverage-
is
also
a
result
in
itself.
But
in
terms
of
bugs
that
we
have
found
first
and
foremost,
what
box
are
we
finding,
and
in
this
case
we
will
find
all
the
box
that
sanitizers
essentially
give
us
so
sanitizers
are
these
kind
of
block
oracles
that
will
be
compiled
into
a
program
in
this
case
c
and
we'll
sort
of
do
heuristics
on
whether
you
find
buffer
overflows
where
they
find
null
dereferences.
A
Those
are
the
majority
of
the
box
that
we
find,
and
a
quick
note
on
this
before
I
show
the
numbers
is
that
not
all
box
are
necessarily
true
bugs,
and
what
I
mean
by
this
is
that
memory
corruption
issues
are
often
thought
of
as
major
issues.
These
are
exploitable
box
that
we
can,
you
know,
use
to
circumvent
the
application
of
fluid,
but
because
of
the
way
fusses
work
they
will
often
be.
A
They
will
often
have
some
level
of
over
approximation
on
the
target
code,
because
we
might
the
data
that
the
faucet
generate
might
not
be
constrained
in
a
way
when
calling
into
a
given
api.
That
fluent
bit
only
so
fluent
will
do
some
manipulation
on
its
data
and
may
not
be
able
to
call
into
certain
apis
with
arbitrary
input.
A
They
include
30
32,
heat
buffer
overflows
and
the
majority
of
these
overflows
will
just
be
off
by
ones
that
are
essentially
not
going
to
have
a
major
impact
or
in
in
essence,
any
impact.
When
you
deploy
a
fluent
bit,
there
will
be
some
stack.
There
are
seven
stack
base
buffer
overflows,
a
bunch
of
heat,
double
freeze
and
also
use
after
freeze
and
then
also
22
nulli
references.
A
So
this
graph
shows
all
the
issues
that
we
have
found
with
fluenbit
in
terms
of
closed
issues
and
open
issues.
What
I
mean
by
that
is
when
oss
first
finds
an
issue,
it
will
put
it
up
on
a
database
in
this
case
monorail,
and
they
will
then.
What
we
have
then
tracked
here
is
the
number
of
closed
issues
and
issues
get
closed
when
they
get
fixed
and
number
of
open
issues.
A
A
A
So
sn
printf
will
take
a
format
string
and
copy
all
that
content
into
a
buffer.
Now
the
point
is
here
that
we
use
this
val
len
argument
to
routine
later
on
this
flb
message:
pack
guelph
value.
We
use
that
as
an
argument
next
to
its
val
buffer
and
val
here,
will
hold
the
content
of
temp,
which
is
at
the
destination
end
of
the
sm
printf
function.
Okay,
now
the
point
is
here
that
sn
printf,
it
returns
so
upon
successful
return.
These
functions
return
the
number
of
characters
printed
to
this
nation.
A
So
the
essential
check
point
here
was
that
then
can
be
should
be
checked
for
whether
it's
larger
than
the
size
of
temp,
and
that
was
essentially
the
fix-
and
this
essentially
returned
in
a
stack
base
buffer
overflow,
because
valve
length
would
be
passed
down
in
the
code
with
a
size
larger
than
temp
and
in
the
code
it
would
be
passed
down
to.
It
would
indicate
the
size
of
the
given
buffer,
which
was
larger
than
the
size
of
the
buffer.
A
Another
example
of
a
bug
it
found
was
in
some
of
the
sign
before
code,
which
is,
I
think,
related
to
some
amazon
logic
had
this
routine.
That
would
compare
key
key
value
pairs,
and
in
this
case
what
actually
happened
was
that
values
could
have
the
null
value
and
therefore
we
would
have
a
null
point
of
the
reference
at
the
second
string.
Compare
here,
so
the
fix
was
really
just
to
check
for
null
values.
A
Those
are
kind
of
the
issues
that
it
will
find
and
a
final
one
here.
What's
the
bug
in
this
case,
the
bug
is
here
that
so
here
we
have
the
the
logic
of
flb
stir
and
dock
and
well.
This
is
also
a
null
pointer
d
reference,
because
if
malloc
fails,
it
returns
null
flb
underscore,
stir
and
dop
will
return
null,
and
essentially
there
is
no
check
on
that
in
the
code,
which
resulted
in
a
lot
of
null
point
of
view.
A
So
what's
future
work,
the
future
work
is
to
essentially
increase
to
a
lot
more
code
coverage.
We're
aiming
to
have
90
code
coverage,
the
forces
to
have
90
code
coverage
throughout
the
the
the
code
by
this
year,
and
we
have
to
do
some
a
little
bit
exotic
techniques
to
actually
reach
that
which
is,
for
example,
to
force
malloc
to
to
fail
and
that
kind
of
stuff.
A
And
then
essentially,
we
will
continue
in
the
current
process
of
find
box
and
sorry
find
gaps
in
the
code
that
are
not
being
hit
by
the
existing
fusses
develop
fusses
that
target
that
code
fix
the
box.
That
may
come
up
and
then
just
rinse
and
repeat
so
that's
it.
For
my
talk.
If
you
have
any
questions
I'll
be
happy
to
answer
them.