Fuzzing Qt for fun and profit

Many KDAB engineers are part of the Qt Security Team. The purpose of this team is to get notified of security-related issues, and then decide the best course of action for the Qt project.

Most of the time, this implies identifying the problem, creating and submitting a patch through the usual Qt contribution process, waiting for it to be merged in all the relevant branches, and then releasing a notice to the users about the extent of the security issue. We also work together with downstreams, such as our customers, Linux distributions and so on, in order to minimize the risks for Qt users of exposing the security vulnerability.

However, that's only part of the story. As part of the security team, we can't simply wait for reports to fall in our laps; we also need to have a proactive approach and constantly review our code base and poke it in order to find problems. For that, we use a variety of tools: the excellent Coverity Scan service; the sanitizers available in GCC and Clang; clazy, maintained by KDAB's engineer Sérgio Martins; and so on.

Note that all these tools help catch any sorts of bugs, not only the security-related ones. For instance, take a look at the issues found and fixed by looking at the Undefined Behavior Sanitizer's reports, and the issues fixed by looking at Coverity Scan's reports.

Today I want to tell you a little more about one of the tools used to test Qt's code: the American Fuzzy Lop, or AFL to friends.

Fuzzing

What is AFL? It's a fuzzer: a program that keeps changing the input to a test in order to make it crash (or, in general, misbehave). This "mutation" of the input goes on forever -- AFL never ends, just keeps finding more stuff, and optimizes its own searching process.

AFL gained a lot of popularity because:

• it is very fast (it instruments your binaries);
• it uses state-of-the-art algorithms to mutate the input in ways that maximize the effect on the target program;
• the setup is immediate;
• it has a very nice text-based UI.

The results speaks for themselves: AFL has found security issues in all major libraries out there. Therefore, I decided to give it a try on Qt.

The setup

Setting up AFL is straightforward: just download it from its website and run make. That's it -- this will produce a series of executables that will act as a proxy for your compiler, instrumenting the generated binaries with information that AFL will need. So, after this step, we will end up with afl-gcc, afl-g++ and so on.

You can go ahead and build an instrumented Qt. If you've never built Qt from source, here's the relevant documentation. On Unix systems it's really a matter of running configure with some options, followed by make and optionally make install. The problem at this step is making Qt use AFL's compilers, not the system ones. This turns out to be very simple, however: just export a few environment variables, pointing them to AFL's binaries:

And that's it, this will build an instrumented Qt. (A more thorough solution would involve creating a custom mkspec for qmake; this would have the advantage of making the final testscase application also use AFL automatically. For this task, however, I felt it was not worth it.)

Creating a testcase

What you need here is to create a very simple application that takes an input file from the command line (or stdin) and uses it to stress the code paths you want to test.

Now, when looking at a big library like Qt, there are many places where Qt reads untrusted input from the user and tries to parse it: image loading, QML parsing, (binary) JSON parsing, and so on. I decided to give a shot at binary JSON parsing, feeding it with AFL's mutated input. The testcase I built was straightforward:

Together with the testcase, you will also need a few test files to bootstrap AFL's finding process. These files should be extremely small (ideally, 1-2KB at maximum) to let the fuzzer do its magic. For this, just dump a few interesting files somewhere next to your testcase. I've taken random JSON documents, converted them to binary JSON and put the results in a directory.

Running the fuzzer

Once the testcase is ready, you can run it into the fuzzer like this:

A few explanatory remarks:

• The testcases directory contains your reference input files, while the findings of the fuzzers will be written in findings.
• To avoid blowing up your system, AFL sets very strict limits for execution of your test: it is allowed to allocate at most memorylimit megabytes of virtual memory and it is allowed to run for at most timeoutlimit milliseconds. You will typically want to raise the memory limit from its default (50MB) to something bigger, depending on your system and on the test.
• One instance of afl-fuzz is single threaded; in order to maximize the search throughput on a machine with multiple cores/CPUs, you must manually launch it multiple times with the same -i and -o arguments. You should also give each instance a unique name and, if you want, elect one instance to do a deterministic search rather than a random one. This is all expressed through the master/slave options: pass to one instance the -M fuzzername option, and to all the others pass the -S fuzzername option. (All the fuzzernames must be unique).
• Last but not least, @@ gets replaced by the name of a file generated by AFL, containing the mutated input.

For reference, I've launched my master like this:

The output is a nice colored summary of what's going on, updated in real time:

Now: go do something else. This is supposed to run for days! So remember to launch it in a screen session, and maybe launch it via nice so that it runs with a lower priority.

Findings

After running for a while, the first findings started to appear: inputs that crashed the test program or made it run for too long. Once AFL sees such inputs, it will save them for later inspection; you will find them under the findings/fuzzername subdirectories:

If you're lucky (well, I guess it depends how you look at it...), you will end up with inputs that indeed crash your testcase. Time to fix something!

You may also get false positives, in the form of crashes because the testcase runs out of memory. Remember that AFL imposes a strict memory limit on your executable, so if your testcase allocates too much memory and does not know how to recover from OOM it will crash. If you see many inputs crashing into AFL but not crashing when running normally, maybe your testcase is behaving properly, but just running out of memory, and increasing the memory limit passed to AFL will fix this.

The sig part in the name of each saved input should give you a hint, telling you which Unix signal caused the crash. In the listing above, signal number 11 is a SIGSEGV, which is indeed a problem. The signal 06 is SIGABRT (that is, an abort), which was generated due to running out of memory.

To reproduce this last case, just manually run the test over that input, and check that it doesn't misbehave; then rerun it, but this time limiting its available memory via ulimit -v memory_available_in_kilobytes. If the testcase works normally but crashes under a stricter ulimit, it's likely that you're in an out-of-memory scenario. This may or may not require a fix in your code; it really depends whether it makes sense for your application/library to recover from an OOM.

Fixing upstream

After reporting the findings to the Security Team, it was a matter of a few days before a fix was produced, tested and merged into Qt. You can find the patches here and here.

Tips and tricks

If you want to play with AFL, I would recommend you to do a couple of things:

• Set your CPU scaling governor to "performance". This is for a couple of reasons: it makes no sense for the kernel to try to throttle down your CPUs if AFL is running; and it is actually a bad thing because it interferes with AFL measurements. AFL complains about this, so keep it happy and disable "powersave" or "ondemand" or similar governors.
• Use a ramdisk for the tests. AFL needs to write a new input file every time it runs your application; for the JSON testcase above, AFL was achieving about 1000 executions/second/core. Each of this run needs a new test file as input; in addition to that, AFL needs to write stuff for its own bookkeeping.This will put your disk under very considerable stress, possibly even wear it out. Now, any modern filesystem will still flush data to disk only a few times every second (at most), but still, why hit the disk at all? One can simply create a ramdisk, and run AFL in there:

• Do not let this run on a laptop or some other computer which may overheat. AFL is tremendously resource intensive and runs for days. If you want to get liquid cooling for your workstation, this is the perfect excuse.

Conclusions

Fuzzing is an excellent technique for testing code that needs to accept untrusted inputs. It is straightforward to set up and run, requires no modifications to the tested code, and it can find issues in a relatively short timespan. If your application feature parsers (especially of binary data), consider to keep AFL running over it for a while, as it may discover some serious problems. Happy fuzzing!