Fuzz testing (automated, random testing) is an important part of nearly every application security life cycle. While there are a lot of tools, frameworks and harnesses available for regular desktop platforms/operating systems, there’s still a lot missing in the mobile sector which is becoming increasingly important.
In this article, I will describe the necessary implementation steps for a mobile fuzzing harness and provide a proof-of-concept implementation called ADBFuzz that allows anyone to run fuzzers written in Javascript in Firefox Mobile on Android. In the near future, we will also likely release internal fuzzers that can be used with this harness.
Basic Requirements for Mobile
The principles of fuzzing are no different on mobile when comparing to desktop platforms, it’s just that the different steps of fuzzing are more complex to implement. To understand the problems we need to solve, we first have to look at these steps from a more general perspective.
The following diagram roughly describes how many fuzzers work:
- We need to be able to start the target program obviously.
- Supply tests to the program, which can either happen by testing from inside the program, or by creating tests externally and sending them to the program.
- While a test is executed, we need to monitor the program for responsiveness and crashes.
- If the program goes non-responsive for a certain amount of time, we can assume that it’s hanging and we terminate the program and go back to the first step.
- If we crash, then we would of course want to triage the crash and e.g. determine if it’s a known problem.
- Based on the triage, we need to save the tests we executed so far in order to be able to reproduce the problem later. Note that based on the correctness assumptions, we might also consider hangs as interesting and process them like crashes (e.g. if our program is not supposed to hang under any circumstances).
Let’s try to apply this information to Mobile: Assuming our target program is running on a mobile device (e.g. tablet, smart phone), we first need a way to communicate with the device to perform basic tasks like start/stop the program and monitor if it’s still running. For Android, the Android Debugging Bridge (ADB), offers the necessary functionality. Using the adb command line tool, we can perform various tasks on the device, including running all sorts of shell commands which should give us enough flexibility to accomplish these steps.
However, we do not need to use the adb command line tool directly: Mozilla has a Python-based abstraction called DeviceManager which supports certain tasks on mobile that are implemented using ADB. Using this implementation, we don’t have to care about low-level shell implementation anymore but can instead use a high-level interface.
Communication with the Program
Since we’re targeting Firefox Mobile, it seems reasonable to have a part of the fuzzer (or even the whole fuzzer), running inside Firefox using Javascript. Based on what is to be tested, we can either implement the whole fuzzer in Javascript, or have the test generation on the host machine leaving only the execution in the browser. Independent of the strategy we choose here, it is desirable to have a bidirectional communication channel between the host-part of the fuzzer and the part running in Firefox Mobile. Since Firefox supports Websockets we can use those to establish a simple connection back to the host machine (Note that programs like em-websocket-proxy can simply relay incoming websocket connections as raw TCP connections, making the server part trivial to write).
Once we have such a connection we can use it to implement responsiveness protocols and logging as it is desired. Optionally we can use it to send tests to the browser to have them executed there.
Crash Triage
In general, crash triage can be done reasonably well once we have a crash stack trace and an optional assertion message. On the desktop, the OS usually provides some form of crash dump, like core dumps on Linux. On Android, this isn’t trivial to achieve. While it’s certainly possible to get core dumps to work on a rooted Android device, it’s impossible without rooting (to my knowledge). But at least for Firefox, we don’t need core dumps, we can use the crash reporter built into Firefox instead. With the right settings, the Firefox crash reporter will create a minidump when it crashes, but not submit it or show a submit screen. Instead it will just exit after having written the dump, which is perfectly suitable for our automated testing.
Once the fuzzing harness detects a crash, we only have to check the minidump directory on the device for any crash dumps, then pull the dump off the device and run a tool like minidump_stackwalker on it to get a crash stack trace.
Proof of Concept
In order to make it easier for security researchers and other interested community members to write fuzzing tools for the mobile platform, I decided to create a proof-of-concept implementation in Python that allows running fuzzers written in Javascript in Firefox Mobile. In order to use it, you need an Android device and either root on it, or a special Firefox build (flagged as “debuggable”). Please see the provided README file for further details. The source code is available in a Github repository:
https://github.com/mozilla/ADBFuzz
For now, the implementation only comes with a “Hello world” fuzzer, that includes the required Websockets communication code but no real fuzzing logic itself. Instead it has a nice little demo that will spin around a <div> tag using CSS transformations. It is up to you to implement any desired “real” testing there. As previously mentioned, we also plan to release certain tools in the future: Jesse Ruderman, author of jsfunfuzz, domfuzz and other fuzzing tools we use at Mozilla, has announced that he will very likely make his tools public in the near future. Some of these tools are compatible with the harness presented here.
Acknowledgements
Special thanks goes to the Mozilla Automations Team (ateam), especially to Joel Maher, Geoffrey Brown, William Lachance and Clint Talbert for helping me with necessary changes around DeviceManagerADB.
– Christian Holler
Security Engineer