►
From YouTube: Last orders at the House of Force
Description
Watch @kevin_backhouse's glibc allocator exploitation tour de (house of) Force in his #HITCON2020 presentation "Last orders at the House of Force"
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
Google+: http://google.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
A
A
A
We
are
trying
to
build
a
community
of
security
researchers
who
are
helping
to
improve
the
security
of
open
source,
and
we
do
our
own
security
research.
Looking
for
vulnerabilities
in
open
source
projects,
I've
been
the
security
researcher
since
approximately
2017.
Before
that
I
spent
most
of
my
career
working
on
compilers
and
recently.
The
thing
that
I've
been
focusing
on
is
ubuntu.
A
A
Okay,
so
now
I
know
it's
traditional
to
if
you've
got
a
doing
a
talk
about
exploitation,
to
build
up
to
the
climax
of
the
end,
where
you
show
the
the
video
of
the
exploit
running,
but
I'm
going
to
do
it
the
other
way
around,
because
I
think
if
I
show
you
the
exploit
running
now,
then
that's
going
to
help
to
give
context
to
what
I
talk
about
in
the
rest
of
the
talk.
A
A
The
exploit
takes
approximately
eight
seconds
to
kick
in
so
there
you
go,
there's
the
calculator
that
just
popped
up
now,
I'm
going
to
show
you
that
again
this
time,
what
I'm
going
to
show
you
is
what's
going
on
in
the
background.
So
let's
start
simple
scan.
A
And
so,
in
the
background
there
you
can
see
some
of
the
communication
that's
happening
with
the
the
fake
scanner.
So
what
I've
done
is
I've
got
another
computer
running
on
my
home
network
that
has
got
this
server
software,
that
is
pretending
to
be
a
network
attached
scanner,
and
so,
when
simplescan
starts
scanning
the
network
for
network
attached
scanners,
it
gets
malicious
replies
from
from
this
fake
scanner,
which
then.
A
Successfully
gets
code
execution
in
simple
scan
now.
Most
of
the
work
involved
in
this
exploit
is
in
getting
to
this
point
that
you
see
just
here
where
what
you
can
see
here
is
that
it
has
received
a
remote
info
leak
with
values
like
the
value
of
the
stack
canary
and
various
addresses
that
allow
it
to
determine
the
aslr
offsets
and
that's
actually,
the
majority
of
the
work
in
getting
this
exploit
to
to
work
successfully
is
getting
to
the
point
where
we
get
that
info
leak.
A
Once
I've
received
the
info
leak,
it's
then
actually
really
quite
easy.
I
send
back
a
response
that
contains
a
a
crafted
rock
chain
that
overwrites
the
stack
and
it
gets
code
execution
very
quickly.
So
most
of
the
work
is
in
getting
to
this
point
and
that's
what
I'm
going
to
be
focusing
on
in
this
talk.
A
A
So,
first
of
all,
I'm
going
to
talk
about
the
the
bugs
that
I
exploited
they're
in
sane,
which
stands
for
scanner
access
now
easy!
That's
the
library!
That's
used
under
the
hood
in
simple
scanner
to
connect
to
the
network
attached
scanners.
A
I
don't
think
that's
the
most
interesting
part
of
this
story.
I
think
it
would
have
been
an
awesome
prank
to
be
able
to
do
that.
Run
that
exploit
on
my
colleagues,
but
I
think
a
genuine
criminal
probably
wouldn't
have
found
this.
This
exploit
to
be
all
that
useful
to
them.
A
So
for
me,
the
the
most
interesting
part
of
the
the
story
is
about
how,
if
you
do
have
a
bug
like
this,
how
you
can
then
use
glib
c
heap
exploitation
techniques
to
actually
defeat
asla
and
get
code
execution
remotely.
A
Okay,
so
these
are
the
bugs
now
you
can
see
that
there's
there's
quite
a
few,
but
the
majority
of
these
bugs,
although
they
were
security,
vulnerabilities
weren't,
useful
to
me
in
as
part
of
getting
code
execution
in
insane,
so
they
were
just
sort
of
remote
denial
of
service
type
bugs.
So
there
were
two
that
were
genuinely
useful,
which
I'm
going
to
show
to
you
now.
A
The
first
bug
is
a
heat
buffer
overflow
that
I
can
trigger
remotely
in
this
function.
Called
epson's
net
read
so
just
notice.
Here,
there's
this
variable
called
wanting.
This
function
is
going
to
read
some
data.
That's
it's
received
off
the
network
and
wanted
is
the
amount
of
data
that
it's
expecting
us
to
receive
and
it
is
actually
pre-allocated
a
buffer
in
order
to
receive
that
number
of
bytes.
A
So
if
you
scroll
down
here,
then
you
can
see
that
it's
reading
a
header
here
from
the
incoming
network
data
and
then
it's
raising
a
size
value
out
of
that
header.
And
then
this
looks
good
here.
It's
checking
that
the
size
matches
wanted,
and
so
this
is
the
case
that
you
hit
when
you're
talking
to
a
legitimate
scanner.
That's
not
trying
to
do
something
malicious,
but
then
down
here.
It's
got
this
other
code
where
it
says.
Well
what
about
if
size
is
bigger
than
wanted?
A
It
still
just
goes
goes
ahead
and
reads
all
of
that
data
into
the
pre-allocated
buffer,
and
so
this
is
a
really
powerful
heat
buffer
overflow
that
we
can
use,
because
we
control
the
amount
of
the
size
of
the
overflow
and
there's
also
no
restrictions
on
what
bytes
we
can
write.
So
there's
nothing!
No
restrictions
along
the
lines
of
it
can
be
only
ascii
characters
or
something
like
that.
We
can
write
any
bytes.
We
want
into
the
buffer
now
there's
one
final
thing
that
I
want
to
show
you
about
this
little
bit
of
code.
A
This
is
something
I
find
quite
quite
interesting
because
this
turned
out
to
be
really
useful.
A
I
mean
this
is
such
a
minor
thing
that
it
wouldn't
even
be
classified
as
a
security
bug
I
mean
all
you're
doing
is
leaking
some
memory
because
you
forget
to
free
it,
but
in
fact
this
turned
out
to
be
really
useful
to
me
when
I
was
writing
the
exploit,
because
what
it
allowed
me
to
do
was
groom
the
heap
by
deliberately
freeing
deliberately
leaking
lots
of
memory
so
that
it
would
never
get
allocated
again
and
that
way,
I
could
make
sure
that
the
memory
allocation
would
happen
from
a
contiguous
sequence
of
addresses.
A
So
when,
when
you
start
up
simple
scanner,
it
immediately
starts
scanning
the
network
for
network
attached
scanners
and
so
the
way
that
it
does,
that
is
by
sending
out
a
udp
broadcast,
and
so
what
my
fake
scanner
is
doing
is
it's
listening
on
port
3289
for
this
broadcast
message
and
when
it
receives
it,
it
sends
back
not
just
one
reply,
but
actually
hundreds
of
replies,
and
what
then
happens
is
that
this,
while
loop
here
is
written
to
handle
the
case
where
there's
more
than
one
scanner
on
the
network
and
so
by
sending
back
hundreds
of
replies,
I
can
actually
make
this
loop
go
round
many
many
times
and
that's
also
really
crucial
for
the
exploit,
because
it
allows
me
to
trigger
the
heat
buffer
overflow
multiple
times.
A
If
I
hadn't
been
able
to
do
that,
I
don't
think
there's
any
way
that
I
could
have
got
a
working
exploit,
because
if
I
had
to
to
get
code
execution
from
the
buffer
overflow
on
the
first
attempt,
I
wouldn't
know
the
aslr
offsets
and
so
I'd
have
no
hope
of
of
actually
having
a
successful
exploit
there.
A
Okay.
Now,
let's
look
at
the
second
bug.
This
bug
is
kind
of
a
a
local
info
leak,
so
the
the
bug
here
is
that
it's
reading
a
number
from
an
attacker
controlled
incoming
message
and
then
what
it
does
is
it
allocates
a
buffer
of
that
size
and
then
it
copies
into
that
buffer.
Here
this
mem
copy.
A
The
problem
is
that
it's
forgotten
to
do
a
bounce
check
to
make
sure
that
it's
not
copying
more
bytes
than
there
are
actually
in
in
buff,
and
so
what
this
allows
me
to
do
is
read
off
the
end
of
the
buffer
and
sometimes
it's
a
buffer.
That's
on
the
stack,
and
sometimes
it's
a
buffer.
That's
on
the
heap.
A
The
drawback
of
this
bug
is
that,
although
it's
an
info
leak,
it's
the
data
that
I've
managed
to
obtain
through
this
bug
is
on
the
wrong
computer.
It's
on
the
victim's
computer,
not
on
on
the
computer,
that
my
fake
scanner
is
running
on,
and
so
in
order
to
get
that
remote
info
leak,
I'm
going
to
have
to
do
something
else
in
order
to
get
this
info
leak
to
actually
help
me
get
a
remote
info
leak.
A
Okay,
so
now
what
are
some
strategies
for
defeating
aslr,
the
most
obvious
one
is
brute
force,
just
try
to
guess
the
aslr
offsets
until
you're
successful
on
a
64-bit
machine.
This
is
pretty
unrealistic,
but
what
people
sometimes
do
is
they're
able
to
maybe
by
getting
a
partial
info
leak,
maybe
find
out
some
of
the
bytes
of
the
aslr
offsets
and
thereby
increase
their
chances
of
guessing
correctly.
A
So
maybe
you
can
get
it,
for
example,
down
to
a
chance
of
1
in
256
that
that
you
will
actually
guess
correctly
and
in
some
scenarios
that's
actually
a
totally
usable
approach.
But
for
me
that's
not
going
to
work
because
my
goal
here
is
to
have
a
prank
that
works
first
time
I
mean
as
soon
as
somebody
starts
up
simple
scanner.
They
immediately
get
get
code
execution.
A
So
maybe
you
can
find
some
bug
whereby
the
the
the
program
actually
just
sends
you
back
all
the
data
that
you
need
and
and
you're
ready
to
go
with
that,
but
that's
kind
of
rare
and
I
certainly
didn't
find
any
bugs
that
were
like
that
in
insane.
A
The
next
possibility-
and
this
is
something
that
you
see
a
lot
in
browser
exploits-
is
if
the
program
that
you're
trying
to
exploit
contains
a
scripting
engine,
then
you
don't
need
a
remote
info
leak.
You
can.
Instead,
if
you
just
have
a
local
info
leak
similar
to
the
one
that
I
just
showed
you
insane,
then
you
can
maybe
just
process
that
locally
I
mean.
Usually
the
kind
of
thing
that
you
need
to
do
is
a
little
bit
of
arithmetic
on
the
aslr
offsets.
A
You
need
to
get
the
aslr
offset
and
then
add
something
to
it
in
order
to
deduce
what
the
pointer
to
some
important
thing
will
be,
and
so,
if
you've
got
a
scripting
engine
in
the
victim
in
the
victim
program,
then
you
can
do
that
on
site
and
you
don't
need
to
ship
it
off.
Unfortunately,
sane
doesn't
contain
a
scripting
engine,
and
so
that
wasn't
a
viable
strategy
for
me
either,
and
so
the
the
final
possibility
that
I'm
aware
of
for
defeating
aslr
is
to
manufacture
an
info
leak,
and
so
that's
what
I
did
insane.
A
Leak
so
earlier
we
saw
a
function
called
epsilon's
net
read,
and
this
is
epsilon's
net
right.
A
They
actually
work
as
a
pair,
so
epson's
net
right
sends
out
a
message
to
the
scanner
and
it
pre-allocates
the
buffer
into
which
it
expects
to
receive
the
ply
the
reply
and
then
netread
receives
the
reply
and
writes
it
into
the
buffer,
and
this
is
this
function
is
the
only
place
where
data
gets
sent
out
over
the
network,
and
so,
if
I
want
to
a
manufacturer
an
info
leak,
then
I
have
to
do
it
in
this
function,
and
so
the
the
strategy
that
I'm
going
to
use
is
down
here
you
can
see.
A
This
is
where
it
does
the
the
tcp
right,
where
it
sends
out
the
data.
What
I
want
to
do
is
I
want
to
overwrite
this
variable
buff
size
make
it
much
bigger
than
it
should
be,
so
that
it
sends
out
a
lot
more
data
than
it
ought
to,
and
in
the
case
where
buff
is
appointed
to
the
stack.
That
means
that
I
then
get
a
leak
of
lots
of
lots
of
data
off
the
stack,
and
that
gives
me
all
the
information.
I
need
to
then
complete
the
exploit.
A
The
problem,
though,
is
that
buff
size
is
actually
stored
on
a
register.
So
how
am
I
going
to
use
some
kind
of
memory,
corruption,
vulnerability
to
change
the
value
of
something
that's
in
a
register?
The
answer
to
that
is
to
do
it
during
a
function.
Call
so
back
up
here.
This
line
that
I've
highlighted
you
see,
there's
a
call
to
malloc
and
during
that
call
to
malloc
buff
size
gets
saved
to
the
stack
and
then,
after
the
calls
malloc
is
finished.
A
It
gets
loaded
back
off
to
the
stack
and
put
back
into
the
register,
and
so,
if
I
can
trigger
a
corruption
of
that
specific
stack
address
during
the
call
to
malloc,
then
I
can
turn
buff
size
into
a
really
big
number,
and
then
I
get
the
remote
info
leak
that
I
need.
A
A
How
how
do
I
trick
malloc
into
writing
garbage
to
stack?
Well,
I
do
that
by
corrupting
the
the
heaps
metadata
so
that
during
that
call
to
malloc
it
actually
has
that
effect
of
overwriting
the
stack,
but
a
really
important
step
that
I
also
need
in
order
to
be
able
to
do
that
is
I
need
to
calculate
the
stack
address
that
I
want
to
overwrite,
and
so
that's
a
local
info
leak
that
I
told
you
about
earlier.
A
What
that
does
allow
me
to
do
is
copy
a
stack
address
into
a
newly
allocated
heat
buffer,
but
the
stack
address
that
I'm
able
to
grab
through
that
process
is
actually
something
like
300
bytes
higher
in
memory
than
the
stack
address
that
I
want
to
overwrite.
So
what
I'm
going
to
need
to
do
is
figure
out
a
way
to
subtract
that
number
300
bytes
from
the
stack
address,
so
that
I
have
the
correct
stack
pointer
in
order
to
set
up
this
heap.
Corruption
in
in
the
malloc
call.
A
Okay.
At
this
point,
I
need
to
mention
the
malloc
malfoycarium.
This
is
a
legendary
document
from
2005
which
introduced
a
number
of
these
classic
glibc
heap
exploitation
techniques
called
things
like
the
house
of
prime
the
house
of
mind
and
the
house
of
force
and
the
house
of
forces.
The
is
the
technique
that
this
talk
is
is
named
after.
Unfortunately,
some
of
these
techniques
no
longer
work
over
the
years.
A
However,
the
at
the
time
that
I
was
writing
this
exploit
the
most
kind
of
current
version
of
ubuntu.
The
most
current
long-term
support
version
of
ubuntu
was
1804
and
1804
ships
with
glibc
2.27,
and
you
can
use
health,
the
house
of
force
on
glib
c
2.27,
so
this
is
kind
of
like
last
chance
saloon
to
write
an
exploit
that
uses
the
house
of
force.
A
A
The
bit
that
I'm
not
quite
sure
about
is
where
these
house
names
came
from.
It's
certainly
not
mentioned
in
the
wikipedia
article,
so
I
think
maybe
those
names
like
the
house
of
house
of
prime
and
so
on
were
actually
invented
by
the
author
of
malfcarium
rather
than
the
malleus
maleficarum.
A
A
What
they've
done
here?
It's
really
cool
they've,
they've,
taken
all
of
those
different
techniques
and
they've
enumerated
them.
So
you
can
see
that
there's
this
there's
kind
of
a
big
long
list
of
all
the
different
techniques
here
and
for
each
one,
they've
created
a
little
demo
program
that
you
can
run
in
gdb,
so
you
can
step
through
and
see
exactly
what's
happening.
So
it's
really
good
way
of
explaining
how
all
these
different
techniques
work.
A
The
way
that
the
allocators
organizes
data
in
the
heap
is
it
has
bits
of
user
data
that
have
been
given
to
the
user
through
malloc
calls
interspersed
with
bits
of
metadata,
and
the
metadata
contains
things
like
the
size
of
the
of
the
chunk,
and
so
let's
just
have
a
look
at
what
that
looks
like
in
memory.
A
So
here's
an
example
where
we've
got
four
chunks
consecutive
in
memory,
and
so
you
can
see
here
that
there's
a
chunk
of
size,
ox10
and
if
you
then
go
ox10
higher
in
memory
you
get
to
chunk
one
which
is
also
size
ox10.
A
That's
been
freed,
so
the
important
difference
here
is
that
when
you
free
a
chunk,
it
starts
also
using
the
user
data
section
as
for
metadata,
and
so
what
you
can
see
here
is
that
the
user,
what
previously
had
been
the
user
data
section
of
the
chunk,
now
contains
two
pointers
which
are
the
forward
and
backwards
pointer,
because
the
chunk
has
been
put
into
a
doubly
linked
list,
and
so
the
important
thing
to
be
aware
of
when
you're
trying
to
do
heap
exploitation,
is
that
you
cannot.
A
However,
these
sizes,
like
the
ox10,
you
can
go
ahead
and
overwrite
those
because
they're
not
affected
by
aslr
offsets.
So
even
when
you're
early
in
the
in
the
in
the
early
stages
of
an
exploit-
and
you
haven't
deduced
the
aslr
offsets,
yet
you
can
overwrite
this
metadata,
because
it's
all
relative
sizes
and
then
later
on,
once
you've
done
something
to
actually
deduce
the
aslr
offsets.
At
that
point,
that's
when
you
can
start
overwriting.
A
A
The
concept
of
the
house
of
force
is
it's
around
the
top
chunk,
so
the
top
chunk
is
a
special
chunk
that
hasn't
yet
been
allocated
from,
and
so,
when
the
the
program
tries
to
allocate
some
memory,
then
what
the
allocator
will
first
do
is
it'll
first
try
to
find
a
chunk
that
can
be
reused.
A
It's
got
various
caches
that
it
can
reuse
chunks
from,
but
if
there's
no
more
chunks
left,
if
everything's
already
been
used,
then
it
needs
to
carve
out
a
new
bit
of
memory
for
you
and
it
does
that
by
going
to
the
top
chunk
and
carving
out
some
new
memory
from
the
top
chunk.
Now,
the
concept
of
the
house
of
force
is
to
use
a
vulnerability,
something
like
a
heat
buffer
overflow
to
overwrite
the
metadata
of
the
top
chunk
and
what
it
does
is.
It
makes
the
top
chunk.
A
Look
like
it's
extremely
big
so
that
so
under
normal
circumstances,
the
top
chunk
would
not
be
that
big.
I
mean
probably
no
more
than
half
a
megabyte,
and
if
you
ask
for
more
memory
than
is
available
in
the
top
chunk,
then
it
will
either
try
to
ask
the
operating
system
whether
it
can
make
the
top
chunk
bigger
or
failing
that
it
will
use
an
map
to
get
some
more
memory
from
the
operating
system,
but
by
overwriting
the
metadata.
A
A
If
we
go
back
ox10,
then
you
can
see
the
metadata
of
the
chunk
that
was
just
allocated,
and
so
you
can
see
that
the
size
of
that
chunk
is
ox-110,
ox10
extra
for
the
metadata
and
then,
if
we
go
to
the
end
of
that
chunk,
you
can
see
there
that's
the
top
chunk
so
that
there
is
the
size
of
the
top
chunk.
A
Which
is
actually
a
negative
number
and
then
allocate
a
block
of
that
size,
and
you
can
see
that
new
point
of
the
block
that
was
just
allocated
is
has
come
from
where
the
the
top
chunk
was
previously,
but
then
the
next
allocation.
A
So
here
we're
going
to
allocate
a
new
chunk
here
and
if
you
look
at
ctr
chunk
there
and
compare
it
to
new
pointer,
you
see
that
actually
the
memory
address
of
ctr
chunk
is
lower
in
memory,
the
new
pointer.
So
you
can
use
this
to
get
the
allocator
to
return
you
a
pointer
to
something
that
it
really
shouldn't
have
given
you
a
pointer
to
so
you
can
then
maybe
do
something
like
overwriting
the
stack
with
it.
A
Okay,
now
I
mentioned
earlier
that
as
part
of
the
exploit,
one
of
the
things
that
I
need
to
do
is
calculate
a
stack
address,
so
I'm
able
to
use
that
local
info
leak
to
copy
a
stack
pointer
into
a
heat
buffer.
But
then
I
need
to
subtract
some
offset
from
that
approximately
300
bytes
from
that.
In
order
to
get
the
stack
address
that
I
want
to
calculate-
and
I
came
up
with
the
idea
of
using
a
variation
on
the
house
of
force
to
do
this.
A
So
the
idea
is,
rather
than
overwriting
the
size
of
the
top
chunk
with
just
a
huge
number.
I'm
instead
going
to
overwrite
it
with
a
pointer
and
then
I'm
going
to
allocate
a
bit
more
memory
and
thereby
shrink
the
top
trunk
slightly
and
that
will
have
the
effect
of
subtracting
an
offset
from
that
that
pointer,
which
I'd
written
into
the
size
of
the
top
chunk.
A
So
that
looks
like
this.
You
see,
there's
a
heap
buffer
overflow,
that's
overwriting
the
top
chunk,
and
so
now
there's
a
stack
pointer
in
the
top
chunk,
and
then
we
allocate
another
chunk
of
memory
and
that
moves
the
top
chunk
up
and
now
the
stack
pointer
has
had
that
offset
subtracted
from
it.
A
So,
let's
step
through
until
we,
so
we
just
allocated
some
memory,
we've
allocated
ox
800
of
memory
and
if
we
print
this
area
of
memory,
so
that's
the
size
of
the
top
chunk
before
anything
happens
and
now
we're
going
to
do
the
vulnerability.
A
A
And
that's
the
top
chunk
now-
and
this
is
the
same
pointer
that
we
wrote
in
before,
but
with
an
offset
subtracted
from
it.
And
so
then
I
can
trigger
that
local
info
leak
yet
again
in
order
to
copy
this
pointer
out
of
that
out
of
that
memory
and
put
it
to
where
I
need
it.
In
order
to
continue
with
the
exploit.
A
Okay,
another
technique
that
I
use
quite
frequently
during
the
the
exploits-
and
this
is
a
relatively
basic
glibc
heap
exploitation
technique.
It's
just
resizing
chunks,
so
the
idea
is
to
use
a
heat
buffer
overflow
to
change
the
size
of
a
chunk
and
usually
what
you
would
use
that
to
do
is
to
make
that
resize
chunk
overlap
with
another
chunk
so
that
you
can
then
corrupt
some
memory
elsewhere.
A
A
Second
chunk
has
grown
and
then,
when
you
free
it,
it
gets
returned
to
the
the
allocator
looking
like
a
different
size
than
it
was
before,
and
so
one
of
the
things
that
I
do
with
that
during
the
course
of
the
exploit
is
to
create
a
chunk
that
overlaps
with
the
top
chunk.
A
So
the
allocator
is
under
the
impression
that
there's
one
chunk
that
is
here
and
it
does
doesn't
realize
that
that
chunk.
In
fact
has
gone
has
over
is
now
overlapping
with
the
top
chuck,
and
so
I
can
use
that
in
conjunction
with
the
local
info
leak
to
grab
that
stack,
pointer
and
copy
it
into
the
metadata
of
the
top
chuck.
A
Okay,
so
what
I've
shown
you
so
far
takes
care
of
getting
that
stack,
pointer,
subtracting
an
offset
from
it
and
then
copying
it
to
somewhere,
where
I
can
use
it
later.
The
next
step
of
the
exploit
is
to
do
something
to
overwrite
the
to
to
actually
trigger
overwriting
that
stat
that
stack
address.
A
So
I
knew
that
that
was
my
goal.
That's
what
I
needed
to
do
so.
I
started
looking
through
the
how
to
heap
repository
for
some
of
these
techniques
and
to
see
if
something
if
there
was
an
existing
technique,
that
would
do
what
I
needed
to
do,
which
is
during
the
call
to
malloc,
write
some
garbage
to
the
stack
by
the
way,
something
I
just
wanted
to
mention
quickly.
A
This
is
part
of
the
reason
that
I'm
very
excited
to
be
talking
at
hitcon,
because
if
you
look
through
this,
how
to
heap
repository
hitcon
is
mentioned
numerous
times.
So
I
think
the
hitcon
conference
has
has
often
been
at
the
forefront
of
developing
new
techniques
for
glibc
heap
exploitation.
A
A
The
problem
with
this
technique,
though,
was
that
it
only
works
with
large
allocations,
so
you
need
to
allocate
more
than
ox
400
bytes
in
order
to
trigger
this
technique,
and
it
turned
out
that
the
constraints
of
what
I
was
working
with
insane
meant
that
I
had
to
trigger
that
overwrite
during
an
allocation
of
64
bytes,
and
so
this
technique
wasn't
going
to
work.
A
So
then
I
started
looking
around
to
see
if
I
could
find
something
similar
that
would
have
a
similar
effect
with
a
small
allocation,
and
what
I
found
was
this
code
in
the
in
the
malloc
implementation
and
the
comment
here
kind
of
sums
up
what
it's
doing
if
you've
exhausted
the
contents
of
the
t
cache,
which
I'm
going
to
explain
to
you
in
a
second,
then
what
it
will
do
is.
A
It
will
then
grab
a
chunk
from
the
fast
bin,
which
is
another
kind
of
cache,
and
what
it
will
also
do
is
it
will
replenish
the
tcash
and
it's
during
that
replenishing
process,
which
is
this
while
loop
here,
but
I'm
able
to
trigger
that
override.
So
I'm
going
to
show
you
some
diagrams
to
show
how
this
works.
A
First
of
all,
let
me
explain
the
t
cash
and
the
fast
spin,
so
the
fast
bin
is,
has
existed
in
the
malloc
implementation
for
much
longer
than
the
t
cash.
The
t
cash
is
a
newer
technique
and
I
kind
of
have
the
impression
that
the
fast
bins
are
obsolete.
At
this
point,
the
the
really
the
t
cache
has
taken
over
as
the
main
cache
of
the
of
the
allocator,
but
the
code
for
the
fast
bins
is
still
there.
A
So
when
you
allocate
some
memory
and
it's
a
small
size,
so
ox
400
or
less
then
the
very
first
thing
the
allocator
does
is
it
tries
to
see
if
there's
an
available
chunk
in
the
t,
cache
and
the
t
cache
is
indexed
by
sizes.
So
if,
for
example,
you
try
to
allocate
64
bytes,
then
it
will
go
to
the
the
slot
for
the
64
byte
chunks
and
see
if
there's
a
chunk
available
for
you.
A
The
t
cache
contains
a
maximum
of
seven
chunks
per
size,
and
that's
going
to
be
important
later
on
in
the
technique
that
I'm
going
to
show
you
okay.
So
if
we
allocate,
if
we
ask
for
a
chunk,
then
it
takes
it
out
of
the
t
cash
first,
and
it
will
do
that
until
the
t
cash
is
empty,
so
allocate
again
comes
from
the
t
cash.
A
Now,
if
we
ask
for
another
chunk
to
be
allocated,
then
it
comes
from
the
fast
bin
because
the
t
cache
is
empty,
but
then
it
doesn't
just
give
you
back
a
chunk
from
the
far
spin
that
code
that
I
showed
you
earlier.
The
effect
of
that
code
is
it
will.
It
will
then
try
to
refill
the
t
cache
from
the
file
spin.
So
all
of
these
remaining
chunks
in
the
fastbend
get
get
moved
over
to
the
t
cache.
So
that
looks
like
this
now.
A
Okay,
so
the
way
that
this
this
technique
works
and
I've
named
the
technique,
fastbin
reverse
into
tcash,
and
I
actually
submitted
a
pull
request
against
how
to
heap
which
has
been
accepted.
So
this
technique
is
now
also
part
of
the
how
to
heap
repository,
and
in
fact
one
of
the
maintainers
told
me
that
this
technique,
although
it
wasn't
in
although
they
didn't,
have
a
demo
in
the
how
to
heat
repository.
In
fact,
this
technique
was
used
as
part
of
the
hitcon
ctf
2019.
A
So
it's
really
important
that
the
code
doesn't
try
to
dereference
this
invalid
pointer,
because
if
it
does,
then
that
will
immediately
crash
the
program.
So
that's
why
we
need
to
have
this
exact
number
of
chunks
in
the
file
spin.
So
what
we've
done
is
we've
used
some
kind
of
vulnerability
to
overwrite
the
pointer
in
g
so
that
it
contains
a
pointer
to
the
stack
address
that
we
intend
to
overwrite.
A
So
what
happens?
Next
we
allocate
a
chunk,
so
a
gets
goes
down
there
into
the
allocated
area
and
then
it
starts
copying
these
chunks
across
into
the
t,
cache
so
b
c:
d,
e,
f
g
and
then
it
thinks
that
stack.
The
stack
pointer
is
another
chunk,
and
so
it
copies
that
across
into
the
t,
cache
now
what's
happened
here,
is
that
it's
written
a
pointer
to
g
into
that
stack
address.
A
Now
important
thing
to
notice
here
is
that
the
fastbin
now
points
to
an
invalid
pointer,
and
so
it's
really
important
that
at
this
point
we
completely
exploit
quickly
because
we're
in
a
very
fragile
state,
where,
if
anybody
tries
to
allocate
another
chunk
of
memory
from
the
fast
bin,
then
the
program
is
going
to
crash.
So
we've
got
to
get
the
exploit
working
quickly
now.
A
But
I
got
really
lucky
here
or
I
feel
like.
I
got
really
lucky,
because
if
you
allocate
one
more
chunk,
then
what
happens?
Is
you
get
back
that
stack
pointer?
And
so
this
actually
was
really
convenient?
For
me
when
I
was
writing
the
exploit,
because
what
I'm
able
to
do
is
after
I've
received
the
remote
info
leak,
I
can
then
send
back
a
crafted
buffer
which,
because
of
this
behavior,
that
the
next
allocation
goes
on.
A
The
stack
that
buffer
that
I
send
back
actually
gets
written
to
the
stack,
and
so
I've
just
received
the
info
leak
containing
the
stack
canary
and
everything
I'm
able
to
craft
a
a
buffer
of
memory
that
gets
that
gets
sent
back
written
onto
the
stack
and
then
I'm
able
to
get
code
execution
very
easily
from
that.
A
Okay.
So
it's
time
to
complete
the
exploit.
This
is
still
a
little
bit
of
a
simplification
of
everything
that
happens
during
the
exploit.
But
these
are
the
major
steps
so
step,
one
is
to
groom
the
heap
and
so
that
memory
leak
that
I
mentioned
to
you
earlier,
where
we
allocate
a
memory,
allocate
some
memory
and
then
forget
to
free
it.
It's
really
useful
for
that
step
of
of
grooming
the
heap,
because
it's
really
important
that
there
are
no
chunks
in
memory
that
are
available
to
reuse.
I
want.
A
I
need
to
be
sure
that
when
it
allocates
memory,
it
comes
out
of
the
top
chunk
in
order
to
get
a
reliable
exploit.
So
then
I
use
the
resizing
chunks
technique
to
create
a
chunk
that
overlaps
with
the
top
chunk.
A
Then
I
use
the
local
info
leak
in
conjunction
with
the
top
chunk
arithmetic
technique
to
grab
that
stack,
pointer,
subtract
the
offset
from
it
and
then
copy
it
to
where
I
need
it.
Then
I
use
the
fastbin
reverse
into
tcash
technique
to
trigger
the
overwrite
of
the
stack
and
then,
as
a
result
of
that
call
to
the
tcp,
send
I
receive
that
info
leak
and
then
I'm
able
to
send
back
my
rock
chain
which
gets
copied
onto
the
stack
due
to
that
behavior
of
the
false,
been
reversed
into
t
cash
technique.
A
Okay,
let's
just
check
that
our
scan
on
my
fake
scanner
is
running.
A
Okay,
so
it's
starting
to
communicate
there.
So
if
we
go
back
here,
we
should
hit
a
break
point
in
a
second
okay.
We've
hit
our
break
point
now.
I
need
to
enable
another
break
point:
okay,
so
we're
in
net
right,
which
is
where
the
buff
size
value
is
going
to
get
corrupted
so
right
here,
let's
see
what
buff
size
is,
so
it's
12
right
now,
I'm
going
to
call
malloc
and
you
see
that
now
buff
size
has
been
overwritten
to
with
a
pointer.
A
So
let's
just
enable
some
more
break
points.
A
So
then
we
get
down
here
and
you
can
see
that
both
size
is
that
number
and
if
we
look
over
here
at
the
fake
scanner,
it's
waiting
for
the
stack
dump
and
so
then,
if
we
step
over
that
function,
you
can
see
that
we've
now
received
our
remote
info
leak
and
some
aslr
offsets
that
sort
of
thing.
A
Okay,
and
so
now
we're
in
the
net
read
function.
The
the
thing
that
you
need
to
watch
now
is
the
stack
frames
in
the
bottom
left
window,
because
this
is
when,
when
the
rock
chain
is
going
to
kick
in
so
that
was
reading
the
header.
A
A
Okay,
so
that
was
just
about
it,
so
sadly
it's
time
to
say
farewell
to
the
house
of
force.
In
fact,
as
soon
as
I've
finished
recording
this
presentation,
I'm
going
to
be
upgrading
my
my
computer
to
ubuntu
2004,
which
is
now
the
latest
long-term
release,
long-term
support
version
of
ubuntu,
and
it
has
glib
c
version
2.31
which
in
which
the
house
of
force
is
no
longer
viable.
A
However,
one
thing
that
did
occur
to
me
after
I
finished
writing
this
exploit
is
that
maybe
you
can
still
do
the
the
top
chunk
arithmetic
techniques
and
maybe
the
house
of
force
isn't
completely
dead
yet
so
the
the
change
that's
happened
in
glib
c.
Is
they
now
check
to
make
sure
that
the
size
of
the
top
chunk
isn't
ridiculous?
A
So
if
it's
say
bigger
than
half
a
megabyte,
then
that
will
get
detected
and
it
will.
It
will
stop
the
program,
but
all
I
really
needed
to
do
was
modify
the
the
final
two
bytes
of
the
stack
address.
A
I
needed
to
subtract
an
offset
of
say
300
bytes
from
that,
and
so
those
are
stored
in
the
final
two
bytes
of
the
address,
and
so
if,
rather
than
copying
the
entire
address
into
the
size
of
the
top
chunk
I'd
instead
just
grab
the
bottom
two
bytes
and
copy
them
into
the
size
of
the
top
junk
applied.
The
top
chunk
arithmetic
technique
to
subtract,
my
offset
from
that
and
then
taken
those
two
bytes
and
then
reconstructed
my
stack
address
from
that.
A
Then
I
think
that
might
have
worked
it
wouldn't
it
would
have
been
a
lot
of
work,
but
I
think
it
might
have
been
possible
to
do
that.
So
one
thing
I
did
just
want
to
mention
is:
it
does
make
me
slightly
sad
that
these
checks
keep
getting
added
to
the
malloc
implementation.
The
glibc
allocator
is
such
a
fundamental
piece
of
software.
It's
used
in
so
much
of
our
software,
and
all
of
these
checks
are
just
making
it
ever
so
slightly
slower.
A
Every
time
they
get
added
and
fundamentally
they're
not
stopping
exploits
from
working.
It
just
makes
it
more
difficult
to
create
a
working
exploit,
but
it
doesn't
stop
it
from
happening
altogether,
and
so
it
seems
to
me
that
the
real
problem
is
that
there
was
a
heat
buffer
overflow
in
the
software
that
was
calling
the
allocator
and
that's
the
problem
that
needs
to
be
fixed.
A
It's
not
the
glib
c
maintainer's
fault
that
the
allocator
can
be
abused
to
get
code
execution
once
you've
got
a
vulnerability
like
that,
and
so
I
I
think
it's
slightly
sad
that.
A
We
keep
adding
more
of
these
checks
to
the
allocator.
I
would
prefer
if
it
was
just
lean
and
fast
code
and
we
focused
on
finding
the
the
vulnerabilities
in
the
code-
that's
using
it
in
order
to
stop
these
kinds
of
exploits
from
being
possible.
So
that's
all
I
had
to
say
I
hope
you
enjoyed
it.
Thank
you.