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: