Bluetooth SDP: Fuzzing the Beast

Source: Dev.to

Introduction

This post continues the discussion on the Bluetooth Service Discovery Protocol (SDP).
SDP transactions occur automatically to discover services on a Bluetooth host, without user interaction. A critical vulnerability in SDP can allow an attacker to cause denial‑of‑service or remote code execution while the user remains unaware.

Background

Notable CVEs

• CVE‑2017‑1000250 – A vulnerability in BlueZ (the Linux Bluetooth stack) that lets an attacker manipulate the continuation state in SDP request packets, leading to an out‑of‑bounds read from the response buffer. All Linux‑based devices, including Android, were affected.
• CVE‑2017‑0785 – Another major SDP vulnerability targeting the continuation state.
• CVE‑2023‑4513 – A Wireshark bug (memory leak in the SDP dissector). Although not a stack vulnerability, it shows that SDP implementations can still contain bugs.

These CVEs demonstrate why systematic fuzzing of SDP is important.

Fuzzing Strategy

The project builds on the ideas from L2Fuzz, which fuzzes L2CAP by mutating core fields rather than sending completely random data. Core‑field mutation increases the likelihood of reaching deeper code paths and obtaining meaningful crashes.

Similarly, this work focuses on mutating core fields of SDP request packets, especially the continuation state, which has proven to be the most promising attack surface.

Continuation State Mutation

An SDP request’s continuation state is defined as:

Continuation State = Length (1 byte) + Continuation Information

Three mutation approaches were explored:

1. Single‑byte mutation – Change one byte within a valid continuation information block. This keeps the mutated value close to a legitimate state, increasing the chance that the server processes the packet rather than rejecting it outright.
2. Full random continuation – Generate a completely random continuation information block and set the length field accordingly.
3. Length extension – Increase the length byte to a value larger than the actual continuation information.

The project implements approaches 1 and 3, mutating a single byte and optionally adjusting the length field.

Random Fuzzing Strategies

In addition to continuation‑state mutation, several broader fuzzing techniques were considered:

• Data‑sequence mutation – Append random changes to UUID or attribute lists. A data sequence can be expressed as:

  Data Sequence = Header + Data Elements
  Data Element  = Header + Data

  Random mutations are injected into the Data portion of elements.

• Bit‑flipping – Randomly invert bits in parameter fields.

• Packet‑level randomization – Construct packets as:

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

  and fill the entire payload with random bytes.

For the prototype, approaches 1 (single‑byte continuation mutation) and 4 (random packet mutation) were selected for implementation.

Implementation Overview

• Continuation state mutation – A single byte within the continuation information is altered; the length field may also be modified to test boundary handling.
• Random packet mutation – Entire SDP request packets are filled with random data to observe how the server reacts to completely malformed inputs.

Future Work

The next post will detail the implementation specifics and present an evaluation of the fuzzing campaign, including observed crashes and potential new vulnerabilities.

Stay tuned for the follow‑up.