1# Bluetooth Stack Fuzzers
2
3## Overview
4Bluetooth stack implements very complex wireless communication protocols and
5scenarios. It's been a hotspot for security researchers and attackers. Fuzzing
6has been used as a popular approach to look for security vulnerabilities in
7Bluetooth stack.
8
9Due to the complex architecture of the Android Bluetooth stack, fuzzing the
10entire stack with pure software is very difficult and impractical. Instead,
11multiple fuzzers are created to target different areas of the BT stack. Fuzzers
12in this directory focuses on the components under `system/stack`.
13
14## Attack surface selection
15For security purpose, remote attack surfaces usually take higher priority since
16they can cause much severe damage comparing to local attacks. This makes the
17incoming BT message handlers our focus. The goal is to be able to pipe randomly
18generated data packets to those message handlers to explore the code path each
19component contains. This helps flushing out any memory/logic issues in the
20remote message handling routine.
21
22Components requiring no authentication, or dealing with messages before
23authentication have a higher fuzzing priority. This includes the SDP, GATT, SMP
24and L2CAP components. A couple post authentication components such as BNEP,
25AVRC, AVCT are also covered by different fuzzers.
26
27## Bluetooth stack overview
28According to Bluetooth spec and the source code, most of the components we care
29here work above the L2CAP layer. In general they work with the following
30sequences:
311. At initialization, a component registers itself to L2CAP with a set of
32callback functions, which, usually contains at least one function handling the
33incoming Bluetooth packets.
342. Each component also exposes certain APIs to upper layers, which can be higher
35level Bluetooth framework, or even applications. Bluetooth framework or
36applications use these APIs to configure the stack, and issue requests.
373. Upper layer also registers callbacks into each component. When a component
38receives a response, it parses and validates the response, extracts the payload
39data, and passes data to upper layer using those callbacks.
404. Many Bluetooth components work in both server mode and client mode with
41different sets of APIs and processing logics.
425. It's common for a Bluetooth stack component to use state machines. The state
43transition happens when APIs are called, or incoming packets are handled.
44
45## Fuzzer design
46The fuzzers are designed to simulate how a component is used in the real world,
47but with a lot of simplifications. Here is how they work in general:
481. First a fuzzer should mock the L2CAP APIs to capture the registration call
49from the target component.
502. At each fuzzing iteration, the fuzzer initializes the target component using
51its initialization function. This will cause the component to register itself to
52L2CAP. Because L2CAP APIs are mocked, the fuzzer will capture the registration
53information, most importantly, the message handler callback function.
543. The fuzzer then calls necessary APIs and callbacks exposed to L2CAP to
55further initialize the target component into either server mode or client mode.
564. Starting from here, the fuzzer splits the input data into multiple packets,
57and feeds them to the target component using the previously captured message
58handler callback.
595. It's common that a fuzzer also needs to call certain APIs to trigger state
60transition of the target component. The fuzzer might use fixed data or data
61derived from fuzzing input to make those API calls.
626. Once all the data is consumed, the target is cleaned up so next iteration can
63start cleanly. It's important to cleanup all the data so there is no state
64pollution between two iterations, otherwise it will be very difficult to
65reproduce a crash.
66
67## Mocking dependencies
68For maximium fuzzing efficiency, the fuzzers are created to include the target
69component and minimium number of other Bluetooth components. This means any
70dependencies from other Bluetooth components need to be mocked. The mocks are
71implemented with a balance of reaching maximium target code coverage and
72minimium development effort. Some of the mocks are simply not implemented.
73
74## Future improvement
75These fuzzers are still far from perfect, with the following possible
76improvements:
771. Code coverage
78
79    It's very important to review the code coverage of each fuzzer. Any big
80    coverage gaps should be analyzed and improved. This can be done by adding
81    additional logic in the fuzzing loop, such as calling certain APIs,
82    providing upper layer callbacks, or changing the mock behaviors.
83
842. Performance
85
86    The fuzzers are designed to run as fast as possible. But there might still
87    be some room to improve the performance. Profiling can be done to figure
88    out the performance bottlenecks, which might be sleeps, tight for loops, or
89    computational heavy operations, such as crypto functions.
90
913. Component coverage
92
93    Currently only 3 fuzzers are created. More should be added so we can cover
94    most of the stack components. With the mocks and design patterns it
95    shouldn't be too difficult.
96