In this post, I will introduce fpicker. Fpicker is a Frida-based
coverage-guided, mostly in-process, blackbox fuzzing suite. Its most significant
feature is the AFL++ proxy mode which enables blackbox in-process fuzzing with
AFL++ on platforms supported by Frida. In practice, this means that fpicker
enables fuzzing binary-only targets with AFL++ on potentially any system that is
supported by Frida. For example, it allows fuzzing a user-space application on
the iOS operating system, such as the Bluetooth daemon bluetoothd – which was
part of the original motivation to implement fpicker.
In the
last blog post,
we discussed how fuzzers determine the uniqueness of a crash. In this blog post,
we discuss how we can manually triage a crash and determine the root cause. As
an example, we use a heap-based buffer overflow I found in GNU readline 8.1 rc2,
which has been fixed in the newest release. We use GDB and rr for time-travel
debugging to determine the root cause of the bug.
This blogpost sheds some light on how fuzzers handle crash deduplication and
what a unique crash is for a fuzzer. For this, we take a look at two contrived
examples and compare the unique crashes identified by
AFL++ and
honggfuzz.
Both examples are similar. They read from STDIN, check if the first character of
the read data is a digit, then call a vulnerable function. The main difference
in test1.c is
that the program crashes directly in the vuln function due to a null pointer
dereference. In
test2.c, a
previously allocated buffer is freed; this buffer is again freed at the end of
main, resulting in libc identifying the double free and raising a sigabort.
Recently I discovered some vulnerabilities in
GNU Readline. These bugs
have been
fixed
in GNU Readline version 8.1.
The case of identifying the vulnerabilities was rather interesting. I wanted to
fuzz another program and wrote a quick harness to test if my setup works. This
test harness used GNU Readline to read input from stdin and passed the data
along to the function under test. I left the fuzzer running while I started to
improve the harness (which would also mean getting rid of GNU Readline as it is
relatively slow for the use-case at hand). However, AFL showed the first crashes
and upon inspection, the vulnerabilities where not in the code I actually wanted
to fuzz but in my systems GNU Readline.
Last week I had the pleasure to attend
Offensivecon 2019 in Berlin. The conference was
organized very well, and I liked the familial atmosphere which allowed to meet
lots of different people. Thanks to the organizers, speakers and everyone else
involved for this conference! Andreas posted a
one tweet tldr of
the first day; fuzzing is still the way to go to find bugs, and mitigations make
exploitation harder. Here are some short summaries of the talks I enjoyed.
I was at the hack.lu conference in Luxembourg this year and attended the fuzzing
workshop, held by René Freingruber from
SEC Consult. I have been curious about this topic
for some years now, but besides doing some manual fuzzing and web-fuzzing, I
never looked into the whole topic that much.
The workshop lasted for around four hours. Before the workshop started each
student got two VMs (Linux/Windows) where everything necessary was already set
up. The VMs included 23 exercises, with step-by-step explanations, source code
and exploits. René started out with an introduction to fuzzing, listing popular
fuzzers and showing an example on how to fuzz with
afl.
Fuzzing is a very old technique to find bugs and vulnerabilities in software.
However it has seen a new push in recent years due to vastly improved tools. The
compilers gcc and clang have received Sanitizer tools that allow finding a lot
of bugs like use after free errors and out of bounds reads that are otherwise
very hard to find.
and thanks for a great time at HES14! A nice
venue (a museum), sweet talks and
stacks of spirit carried us through the three day con. It all set off with a
keynote byTROOPERs veteran Edmond ‘bigezy’ Rogers, who stuck to a quite simple
principle: “People do stupid things” and I guess every single one of you has
quite a few examples for that on offer. Next to every speaker referenced that
statement at some point during her/his talk. Furthermore we presented an updated
version of our talk
LTE vs. Darwin,
covering our research of security in LTE networks and potential upcoming
problems.
Within the last months I had some time to work on my code and today I’m
releasing some of that: a new version of dizzy as well as two new loki modules.
Dizzy is able to use neighbor
travis’ facedancer
to emulate a client device. Two fuzzing modes are available for USB descriptor
fuzzing and USB endpoint fuzzing.
Here is an example cmd to start usb configuration descriptor fuzzing: