File Format Fuzzing in Android – Giving a Stagefright to the Android Installer
Alexandru Blanda (Intel Corporation)
The presentation focuses on revealing a fuzzing approach that can be used to uncover different types of vulnerabilities inside multiple core system components of the Android OS. The session will be targeted on exposing the general idea behind this approach and how it applies to several real-life targets from the Android OS, with examples of actual discovered vulnerabilities. These vulnerabilities affect critical components of the Android OS and the audience will have the opportunity to learn about the way they were discovered and possible exploit scenarios. The most important targets that will be included in the talk: the Android APK installer and the Stagefright media framework.
An approach that can be used for file-format fuzzing on Android
File Format Fuzzing
First steps in file format fuzzing:
- Data Generation
- Log process (Execute Tests)
- Triage mechanism
- Analyze and Debug crashes
If the fuzzing is successful, triage and categorization of the issues is an important step to avoid being overwhelmed by responses.
Mutational vs. generational Fuzzing
Maintain the structural validity of the file being processed. The target needs to accept that the file is valid otherwise it won’t run.
Tools use for test-case generation:
- Basic Fuzzing Framework (BFF)
- American Fuzzy Lop (AFL)
To find out what’s happening with the test-cases we send to the Android device, we need to check the logs. This can be read out using the logcat on the device. This can be done by looking for Fatal messages and seeding the logcat before and after the run to identify the test case details and information required to reproduce.
adb shell logcat -v time *:F
Each time a crash occurs a tombstone file is created under /data/tombstones and /data/system/dropbox. This data is important to have for triaging the issues and tracking the various crashes.
By looking at the value where the crash occurs you can collect a unique list of crashes without duplicates.
- Parse logcat for input that causes crashes
- Execute input to cause the crash again
- Grab the Tombstone data to check against existing know issues
Analyze and Debug Crashes
After triage maybe you have 2 or 3 interesting crashes to investigate. Using the Tombstone data can give a good indication of the severity and location of where the crash occurs. Dmesg also gives a good source of information.
Using gdbserver you can debug crashes on the device. gdb can then be used to start a remote debugging session (make sure you set the Android debugging symbols).
addr2line can be useful in getting the information on where the call took place (example: where libstagefright called libc.so)
Fuzzing the Stagefright Media Framework
Media files are interesting attack vectors as the contain complex data and result in a large attack surface (audio, video, images, etc…). Media files are also seen as innocuous to users, and can be played through various sources without the users consent (MMS etc..).
Easiest way to test was the build the stagefright CLI tool (frameworks/av/cmds/stagefright) and calling it from the Android command line for testing.
Initially started fuzzing in early 2014… thousands of crashes (needed a triage mechanism to cope). First severe issues reported to Google in September 2014.
Fuzzing the Android application installer
The application installer is an attractive target (runs with high system privileges). If an attacker can exploit this, the impact will be high. The installer also allows for unprivileged users to send input to system components.
The process of application installation differs between ART and Dalvik (Lollipop and KitKat respectively).
Extract the APK, fuzz the components to be tested, repack
ART is easier as alterations can be made without extraction.
Modifications to the APK will result in an application signature mismatch. This means that the APK will need to be re-signed before testing.
Fuzzing with AFL in Android
Android port of the tool developed by Adrian Denkiewicz of Intel
Using alongside MFFA to discover issues. In some cases, AFL reported crashes that could not be confirmed when running the test case singularly.
This method of testing showed some results that were not seen in other tests (1 high RCE issue, and several low severity issues).