►
Description
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
B
All
right,
so
we're
not
going
to
be
showing
anything
cool,
and
everyone
can
see
my
screen,
I
assume
yeah,
good
okay,
so
we're
not
going
to
be
showing
anything,
cool
and
and
graph
QL
tools
are
actually
quite
interesting
for
anyone
who
has
to
deal
with
them.
Any
any
help
we
can
get
there
is
is
super
helpful,
so
that
was
really
neat
Andrea.
B
Bobby
and
I
are
going
to
talk
about
existential
sadness,
but
at
a
light
evening
pace
so
we're
going
to
go
through
some
of
the
the
top
four
vulnerabilities
that
we
see
in
golang
projects
that
we
really
like
developers
to
stop
to
stop
having,
and
my
name
is
Stefan
Edwards
I
in
the
practice
lead
for
commercial
services
here
at
Trello
bits.
You
can
find
me
basically
anywhere
as
logical
I'm
joined
by
Bobby
tonic,
he's
a
senior
apps
tech
engineer
here.
B
Twitter
handle
Bobby
tables
and
he's
on
github
as
B
tonic,
and
we
both
work
at
Trello
bits,
Bobby
and
I,
although
I
run
commercial
services,
Bobby
and
I
also
work
together
in
our
apps
X
sub
group
as
well.
So
we
we
see
a
lot
of
go.
We
worked
on
the
kubernetes
threat
model
and
a
technical
review
together.
We've
done
a
number
of
block
chains
that
sort
of
thing.
B
B
So
we'll
be
swapping
back
and
forth
going
through
each
of
these,
and
we
want
to
show
you
what
these
problems
are,
how
to
find
them
and,
most
importantly,
how
to
fix
them
so
that
we
can
stop
seeing
them
in
our
code
and
other
other
auditors
can
stop
seeing
them
as
well.
And
if
you,
if
you
take
anything
away
from
this
talk,
it's
the
fact
that
go
has
some
nuances
and
there's
some
edge
cases
that
people
are
really
not
expecting
to
see
when
they're
working
with
them.
B
I
think
there's
a
lot
of
interesting
things,
especially
around
numerix
and
around
error
handling,
and
what
not
that
they're,
not
unintuitive,
but
they
may
not
be
the
first
thing
that
you
think
of
whenever
you
you
hop
into
a
go
codebase
and
I.
Think
a
number
of
these
are
actually
fairly
easily
uncovered.
There's
nothing
really
tricky
about
these.
There's
nothing
really
dense
about
these,
but
if
you're
unaware
of
them,
you
may
not
actually
be
looking
for
them
when
you're
writing
go
or
when
you're
auditing
go
yourself,
and
we
give
hints
to
to
go
tooling
and
I.
B
Think
most
people
have
seen
gos
tooling
and
can
be
complex
and
hit
or
miss,
but
we
do
give
some
hints
into
what
we
use
for
tooling
and
the
sorts
of
things
that
we
do
to
look
for
these
things.
So
it
makes
sense
for
everyone,
so
those
integers
are
are
actually
fascinating
when,
when
this
this
code
is
somewhat
taken
from
from
kubernetes
itself.
B
This
is
something
that
Bobbie
actually
discovered
during
the
assessment,
and
the
thing
that
we
very
frequently
see
is
that
you
know
integers
and
go
are
actually
machine
with,
but
they
are
not
necessarily
typed
in
the
way
that
most
people
expect.
So
on
a
32-bit
machine
you
may
have
an
int,
but
an
int
is
actually
32
bits
wide
and
so
the
semantics
of
house
there
comes
a
I
work
are
actually
dependent
on
which
machine
it's
being
run
on.
B
So
the
the
first
code
snippet
here
and
I,
use
this
in
in
Argos
security
class
and
whatnot
as
a
like
I
gotcha
like
who
can
guess
what
this
does?
It
actually
depends
on
which
machine
you
run
this
on
so
32-bit
wide
machine,
there's
actually
truncation
before
it's
turned
into
an
integer
and
then
the
conversion
to
an
int
32
works
as
you
would
expect
save
for
it's
truncated.
So
it's
a
different
value
than
you
may
expect,
and
on
64-bit
machines,
there's
actually
a
down
cast
and
you
have
a
truncation
there
as
well.
B
So
Bobby
actually
noticed
this
in
cube
cuddle
on
the
client
side
and
was
able
to
bypass
some
of
the
things
that
we
were
expecting.
You
know
cube
cuddle
to
do
as
we
were
looking
through
integer
numerix.
So
the
takeaway
is
just
that.
Integers
are
not
exactly
what
people
expect
and
go.
Apparently,
since
we
see
these
issues
effectively
everywhere
and
again,
it
may
seem
very
obvious,
but
we've
seen
this
across
projects
in
CNC,
F
we've
seen
this
in
block
chains
that
we
worked
in.
We
seen
this
in
web
applications,
etc.
B
So
while
everyone
on
the
call
may
may
think
that
this
is
quite
normal
or
made,
this
is
as
obvious.
We
see
it
quite
frequently,
and
so
the
the
one
thing
I
think
most
people
probably
should
avoid
as
much
as
possible
is
their
comp.
A
tie
is
almost
certainly
wrong
for
the
code
that
you're
working
on
there
are
certain
cases
where
it
makes
sense.
You
don't
care
necessarily
what
what
precision
of
the
integer
you're
working
on
you
don't
care
about.
B
You
know
you're
not
actually
worried
about
overflows
and
those
sorts
of
things,
but
for
the
most
part
you
probably
should
not
be
using
stir
cons
a
tie,
and
you
should
always
odd
it
flows
from
parson
or
pursuant
to
a
different
type.
So
one
of
the
things
that
we
saw
and
then
Nico
automated
with
code
QL
was
with,
was
to
find
flows
that
went
from
something
with
parse
int
to
an
832
and
I
actually
wanted
to
call
out
the
one.
We
did
not
catch
this
during
our
assessment,
but
Nico
actually
caught
this
with
code.
B
Ql
I
simplified
it
for
for
this
talk,
but
basically
someone
was
attempting
to
parse
a
scientific
notation
using
parse
int
and
then
ended
up
down
casting
it
afterwards,
so
they
they
ended
up
with
different
different
widths.
Here
you
can
see
they're
parsing
for
64,
but
then
they're
down
casting
the
32
so
that,
just
whenever
you
see
these
sorts
of
flows,
whenever
you
see
anything
going
from
a
integer,
parse,
int,
64
bits,
wide,
etc
down
to
a
32
bit
or
anything.
B
But
code
ql
has
has
been
very
interesting
for
hunting
these
sorts
of
things
down
for
us
as
well.
So
we
do
a
lot
of
this
manually,
but
code
ql
itself
can
actually
handle
these
things.
So
very
interesting
thing
also
a
very
small
thing,
but
we
really
prefer
that
people
stop
using
integers
and
whatnot
in
these
ways.
So
Bobby
you
want
to
take
it
away.
C
Sure
so
I'm
gonna
kind
of
switch.
The
topic
just
a
little
bit
to
focus
on
like
the
things
that
are
there
and
that
we
use
almost
every
day
so
standard
libraries
are
effectively
the
building
blocks
of
like
most
software
right
and
in
theory
they
should
avoid
exposing
useful
behavior,
but
this
doesn't
typically
happen
even
in
standard
libraries
and
so
a
quick
example
of
this
one
is
the
OS
that
makes
our
all
and
io
util
dot
right
file.
C
C
So
in
the
OS
that
makes
our
all
situation
it'll
populate
a
directory
if
it
already
isn't
there,
but
if
it
is
there
well,
if
you
get
onto
the
next
slide,
real
quick
yeah,
so
basically
populating
the
directories,
if
they
don't
already
exist,
is
a
very
important
detail,
mostly
because
you
can
pass
the
particular
mode
that
they
need
to
be
created
with
right.
But
what
happens
if
some
of
the
directories
in
the
path
exists?
But
with
different
permissions
than
we
expect
right,
that
is
a
very
granular
detail.
C
It's
like,
oh
well,
if
I
specify
a
path
with
the
given,
you
know
set
of
permissions,
then
it
should
just
create
that
path
with
those
permissions,
but
if
they
already
exist,
then
what
if
it
breaks
something
along
that
path
right,
so
it's
not
intuitive
at
first,
when
you
look
her
into
it,
it's
even
weirder-
and
this
is
also
to
note
that
the
same
type
of
thing
happens
with,
like
writing
a
file
and
those
types
of
things.
What
if
the
file
already
exists
and
to
kind
of
sprinkle
it
on
top.
C
This
is
all
before
you
mask
is
applied,
so
the
real
kicker
here
is
like
you
need
to
be
checking
your
permissions
for
whether
they
are
held
before
you
make
them
after
you
make
them,
because
there
are
lots
of
different
factors
that
could
come
and
effectively
do
something
that
you
didn't
want
it
to
do.
Like
a
you
mask,
you
think
that
you're
creating
a
file
with
a
particular
permission
set.
It's
not
like
does
the
directory
already
exist
with
a
different
set
of
permissions?
Yes,
then
it's
not
going
to
make
it
with
that.
C
So
an
attacker
can
effectively
use
this
through
pre-population
attacks
right
if
they
know
that
a
particular
file
is
sensitive
information,
it's
going
to
be
at
a
particular
location
and
the
program
hasn't
run,
yet
they
can
just
pre
populate
it,
but
overly
permissive
permissions.
And
thus,
when
you
go
in
and
actually
tale
said
file,
you
could
potentially
see
sensitive
information.
So,
for
example,
in
the
commodities
assessment
right
there
were
creds
in
logs.
If
you
had
debugging
enabled
that's
not
a
good
thing,
but
an
attacker
could
potentially
use
that
to
get
access
to
other
facts.
Next
slide.
B
But
someone
might
take
me
to
task
that
there's
actually
only
three
of
these
on
here
and
we
can
obviously
discuss
that
at
the
end
of
this.
But
in
in
terms
of
how
goes
error
handling
works,
we
see
these
sorts
of
patterns
continuously.
Someone
accidentally
assigns
to
error
twice
within
two
assignments:
they
use
a
type
researching
without
an
OK
check,
or
they
do
the
wrong
thing
with
air.
So
we
Bobby
and
I
were
on
an
assessment
just
recently
where
someone
was
accidentally.
B
So
we
actually
see
quite
a
few
quite
a
few
type
assertion
issues
with
and
panics,
especially
around
Network
parsing
code.
We
do
a
large
number
of
block
chain
assessments
here
at
trial
bits.
A
lot
of
the
work
that
we
do
is
bespoke
block
chains,
and
so
one
of
the
first
things
that
we
actually
look
through
OS
is
just
a
simple
air
check
and
often
with
asserts
to
see
where
we
can
actually
pull
through
code
bases
and
and
look
for
areas
that
look
like
there's.
B
A
type
assertion
that
may
be
user
controlled
may
be
something
that
we
would
be
interested
in
and
then
start
to
start
to
attack
it
from
there
now.
You'll
also
note
that
I'm
I'm,
suggesting
that
you
use
in
F,
assign
the
why,
if
you're
a
code
auditor
or
if
you
are
hunting
for
bugs-
and
you
have
you
have
this
sort
of
thing
go
itself-
will
not
complain
if
you
assign
to
error
twice.
B
So
very
often
we
see
areas
where
error
handling
meant
to
check
the
first,
the
first
error
and
then
an
issue
or
more
code
was
written
and
we
we
forgot
to
check
the
return
value
there
and
the
program
continues.
So
these
three
err
check
and
nf2
sign
are
our
probably
our
our
bog-standard,
besides
just
using
our
two
fists
to
find
these
sorts
of
things
and
the
other
thing
to
you-
and
this
goes
for
any
type
of
security
testing.
B
Please
fuzz
the
stuffing
out
of
everything
that
you're
doing,
especially
if
you
have
network
parsing
code.
We
find
a
lot
of
a
lot
of
very
simple
low-hanging
fruit,
just
with
Radames
ax
or
fuzz
Letran,
or
those
sorts
of
fuzzers,
even
against
go
code
or
Russ
code
itself.
So
we
can
find
these
things
relatively
quick,
just
with
with
very
simple
and
low-hanging
fruit.
B
Try
to
avoid
types
of
type
assertions
I
understand
that
if
you're,
if
you're
doing
serialization
or
you're
doing
certain
other
techniques,
you
have
to
have
to
use
this,
and
if
you
do
always
make
sure
that
you
are
checking
that
okay
is
true.
There's
a
number
of
locations
where
Bobby
and
I
have
landed,
exploits,
and
others
on.
Our
team,
of
course,
have
landed
things
just
by
someone
using
a
type
conversion,
and
now
we
have
a
panic
from
from
a
very
simple
attacker
controlled
position.
B
C
Yeah
so
effectively
defer
is
crucial
in
a
lot
of
the
exception,
handling
endo
right.
You
know
you
have
the
typical
defer
panic
recover
approach,
and
this
is
all
fine
and
dandy
right.
Sometimes
you
might
defer
a
resource
close
or
a
resource,
tough
finish
to
clean
something
up
after
you
use
it
in
a
particular
function,
scope
and
that's
great,
but
there
are
some
areas
that.
C
Could
effectively
lead
you
down
the
wrong
path
as
far
as
its
semantics
go
go
to
the
next
slide,
so
when
deferring
a
function
the
value
is
returned
are
often
at
North,
including
error
values.
So,
for
example,
if
you
open
a
file
to
write
to
it
right
and
you
defer
file,
duck
close
that
will
effectively
run
after
that
functions.
Body's
function,
body
has
completed,
but
before
the
return
and
say
you
might
have
you
know,
maybe
you
wrote
a
bunch
of
content
into
it
and
the
buffer
hasn't
yet
entirely
written
or
there
was
an.
C
There
was
an
error
when
flushing
to
this
or
similar
right,
because
you
deferred
that
file
that
closed
you
will
not
be
able
to
recover
that
error
value.
It
is
effectively
lost
in
the
void.
No
panic
will
occur
because
of
it.
It
just
kind
of
happens.
Furthermore,
say
you
called
finish
on
something
and
dot
finishes.
C
C
So
you
differ
appropriately
right,
but
it
recover
cool,
but
that
recover
happens
maybe
in
an
inner
loop
of
a
nested
loop,
and
so
it
doesn't
actually
necessarily
match
up
right.
You
might
have
one
extra
call
that
panics
and
there
is
no
recover
above
it
on
that
stack.
So
when
that
is
executed
effectively
that
gets
raised
to
the
parent
caller,
so
is
effectively
an
unhandled
exception.
C
C
If
you
are
going
to
enumerate
the
values
that
are
passed
to
panic,
there
are
lots
of
weird
bugs,
like
an
that,
can
happen
when
you
pass
nil
to
panic
so
effectively.
If
you
maybe
switched
up
your
variables
right
and
instead
of
error,
you
have
your
expected
variable
and
you
pass
that
as
a
panic,
because
you're
like
okay
cool,
it's
gonna
have
a
message
not
necessarily,
and
that
can
actually
break
almost
every
recover
case
and
then
finally
revert
this
review.
C
The
specification
specifically
the
defer
semantics
are
super
super
granular,
because
a
lot
of
people
have
run
into
these
issues
passed
by
copy
versus
passed
by
reference.
When
you
actually
invoke
the
defer
statement
is
super
important
understanding
when
the
defer
statement
actually
executes
before
a
return
and
a
bunch
of
other
different
scoping
rules
for
like
inline
functions.
All
these
things
matter,
because
they
are
easy
things
to
mess
up
on
the
go.
Compiler
will
not
save
you
from
a
lot
of
these
issues
and.
B
Bobby
hates
it
when
I
say
this,
but
defer
and
whatnot
are
effectively
delimited
continuations,
if
you're
familiar
with
with
that
PLT
semantics,
but
or
unwind
protect
and
whatnot
in
Lisp,
but
this
is
actually
part
of
a
larger
talk
that
I
gave
it's
it's
my
Kyoto
Kyoto
School
of
Gonia
lism.
So
if
you
want
to
see
more
of
these
there's
a
bunch
there,
but
hey
everyone.
If
you
have
questions,
we
can
take
them
a
chat
because
I
know
we're
running
on
time.
So
but
thanks
everyone.