Bluetooth Stack Fuzzers

Overview

Bluetooth stack implements very complex wireless communication protocols and scenarios. It's been a hotspot for security researchers and attackers. Fuzzing has been used as a popular approach to look for security vulnerabilities in Bluetooth stack.

Due to the complex architecture of the Android Bluetooth stack, fuzzing the entire stack with pure software is very difficult and impractical. Instead, multiple fuzzers are created to target different areas of the BT stack. Fuzzers in this directory focuses on the components under system/stack.

Attack surface selection

For security purpose, remote attack surfaces usually take higher priority since they can cause much severe damage comparing to local attacks. This makes the incoming BT message handlers our focus. The goal is to be able to pipe randomly generated data packets to those message handlers to explore the code path each component contains. This helps flushing out any memory/logic issues in the remote message handling routine.

Components requiring no authentication, or dealing with messages before authentication have a higher fuzzing priority. This includes the SDP, GATT, SMP and L2CAP components. A couple post authentication components such as BNEP, AVRC, AVCT are also covered by different fuzzers.

Bluetooth stack overview

According to Bluetooth spec and the source code, most of the components we care here work above the L2CAP layer. In general they work with the following sequences:

1. At initialization, a component registers itself to L2CAP with a set of callback functions, which, usually contains at least one function handling the incoming Bluetooth packets.
2. Each component also exposes certain APIs to upper layers, which can be higher level Bluetooth framework, or even applications. Bluetooth framework or applications use these APIs to configure the stack, and issue requests.
3. Upper layer also registers callbacks into each component. When a component receives a response, it parses and validates the response, extracts the payload data, and passes data to upper layer using those callbacks.
4. Many Bluetooth components work in both server mode and client mode with different sets of APIs and processing logics.
5. It's common for a Bluetooth stack component to use state machines. The state transition happens when APIs are called, or incoming packets are handled.

Fuzzer design

The fuzzers are designed to simulate how a component is used in the real world, but with a lot of simplifications. Here is how they work in general:

1. First a fuzzer should mock the L2CAP APIs to capture the registration call from the target component.
2. At each fuzzing iteration, the fuzzer initializes the target component using its initialization function. This will cause the component to register itself to L2CAP. Because L2CAP APIs are mocked, the fuzzer will capture the registration information, most importantly, the message handler callback function.
3. The fuzzer then calls necessary APIs and callbacks exposed to L2CAP to further initialize the target component into either server mode or client mode.
4. Starting from here, the fuzzer splits the input data into multiple packets, and feeds them to the target component using the previously captured message handler callback.
5. It's common that a fuzzer also needs to call certain APIs to trigger state transition of the target component. The fuzzer might use fixed data or data derived from fuzzing input to make those API calls.
6. Once all the data is consumed, the target is cleaned up so next iteration can start cleanly. It's important to cleanup all the data so there is no state pollution between two iterations, otherwise it will be very difficult to reproduce a crash.

Mocking dependencies

For maximium fuzzing efficiency, the fuzzers are created to include the target component and minimium number of other Bluetooth components. This means any dependencies from other Bluetooth components need to be mocked. The mocks are implemented with a balance of reaching maximium target code coverage and minimium development effort. Some of the mocks are simply not implemented.

Future improvement

These fuzzers are still far from perfect, with the following possible improvements:

1. Code coverage

   It's very important to review the code coverage of each fuzzer. Any big coverage gaps should be analyzed and improved. This can be done by adding additional logic in the fuzzing loop, such as calling certain APIs, providing upper layer callbacks, or changing the mock behaviors.

2. Performance

   The fuzzers are designed to run as fast as possible. But there might still be some room to improve the performance. Profiling can be done to figure out the performance bottlenecks, which might be sleeps, tight for loops, or computational heavy operations, such as crypto functions.

3. Component coverage

   Currently only 3 fuzzers are created. More should be added so we can cover most of the stack components. With the mocks and design patterns it shouldn't be too difficult.