Bluetooth SDP: Fuzzing the Beast

This is a continuation of my last post on Bluetooth Service Discovery Protocol.

Why fuss about the fuzz?

In a typical SDP transaction, there is no user interaction as SDP is used automatically to detect services from a Bluetooth host. If there is a critical vulnerability in SDP, a malicious actor may exploit the vulnerability and cause denial of service or remote code execution on the target device. When such event happens, the user of the target device may be oblivious as the SDP transactions are transparent to the user.

To demonstrate the importance of detecting vulnerabilities in SDP, we can look at CVE-2017-1000250.

CVE-2017-10000250 is a vulnerability in BlueZ, Linux Bluetooth stack implementation. The vulnerability allows the attacker to control the continuation state within SDP request packets and cause the SDP server to return an out-of-bounds read from the response buffer. As this is a Linux Bluetooth stack, all Linux-based devices were affected, including Android devices.

This vulnerability was featured as one of the attack vectors in Blueborne malware, which exploit multiple Bluetooth vulnerabilities.
CVE-2017-1000250 and CVE-2017-0785 were the last known major vulnerabilities for Bluetooth SDP. Although there was a recent vulnerability related to SDP (CVE-2023-4513), it was a Wireshark bug due to a memory leak in its SDP dissector. It does not mean that the current SDP implementation of the Bluetooth software stacks have no vulnerabilities or bugs. There may exist a vulnerability that has yet to be discovered.

Core field Mutations

The project was initially proposed to be an extension of L2Fuzz. L2Fuzz fuzzes the L2CAP by focusing mutating the core fields in L2CAP. By mutating only the core fields, we are able to send packets that are more likely to cause a crash, which may reveal a bug that leads a vulnerability. Of course we can send totally random inputs, but if a random input would most likely be rejected by the server. Performing a core field mutation also allows us to zoom into the particular message processing part should we discover a bug.

In the spirit of L2Fuzz, the project also looks into core field mutation of the SDP request packets.

A SDP request typically consists of a PDU header, parameters and continuation state. Looking at the error responses which a SDP server can generate, it seems that the SDP server will reject any request where the fields are mutated. Most mutated packets are likely to be rejected by the SDP server. Further experimentations with various fuzzing strategies have shown that the mutated packets were all met with various error responses. One exception is the continuation state, where appending additional data to a valid continuation state may result in a valid SDP response. While it may be because we did not modify the length parameter of the continuation state, fuzzing the continuation state is the most promising strategy to detect any bug or vulnerability in SDP.

Continuation State Mutation

In CVE-2017-1000250 and CVE-2017-0785, the vulnerabilities targeted at the continuation state of SDP requests. While SDP has error response regarding invalid continuation state, it would be worthwhile to consider mutating the continuation states.

The continuation state of a SDP request can be broken down into the following:

Continuation State = Length of Continuation State (1 byte) + Continuation Information

We consider 3 approaches in mutating the continuation states:

1. Mutating a single byte from an actual continuation information. This approach ensures that the mutated value is close to a valid continuation state. By fuzzing with a mutated continuation state close to a valid state, we increase the chance of the packet not getting rejected, thus allowing us to detect any bug with higher probability.

1. Generating a full random continuation information and set the length of the continuation state to the length of the new random value.
   This approach is similar to the approach #1. However, the mutated continuation state may be a totally different value from a valid continuation state. This may result in more rejected packets but it might trigger bugs that occurs in the rejection code.

2. Modify the length of the continuation to a higher value.
   This approach differs from the first 2 approaches as it directly manipulates the length value of the continuation state. This approach can also be used in tandem with the first 2 approaches or independently. By modifying the length to a higher value, the fuzzer might be able to detect a read out of bound error, which can be used as an exploit.

Random Fuzzing

While we want to inherit the key techniques outlined by L2Fuzz, we want to increase coverage of the fuzzing exercise as well.

There were a few approaches that were considered:

1. Adding random mutations to the data sequences (UUID lists or attribute lists). This is similar to the continuation states mutation. Instead of mutating the continuation states, we mutate the parameters in the data sequences. A typical data sequence in SDP can be generalized into the following:

Data Sequence = Data Sequence Header + Data Elements

Where a typical Data Element can be generalized into the following:

Data Element = Data Element Header + Data

In this approach, we will append random mutations into the Data of the data element.

1. Flipping random bits in the parameters.
   In this approach, we can flip random bits in the packets.

2. Appending random mutations into the packets.
   This is similar to the continuation states mutation. However, the appended mutation will not be counted as part of the continuation states. In this approach, the request can be generalized into the following:
   

SDP Request = PDU Header + Parameters + Continuation State + Random Mutation.

1. Generating totally random byte data for the packets. This approach simply generates random byte values as the packet data and send to the SDP server.

In the project, we selected Approach 1 and 4 for implementation. For continuation state mutation, we mutate a single byte in the continuation state and the length parameter of the continuation.

Next post, I will touch a bit on the implementation and discuss the evaluation of the project. Till next time~