CVE-2024-34727 - Heap Buffer Overflow Vulnerability in `sdp_utils.cc` Enables Remote Information Disclosure (Analysis and Exploit)

A new security flaw, CVE-2024-34727, has been discovered in the sdpu_compare_uuid_with_attr function within the widely used Bluetooth stack implementation. This issue revolves around a heap buffer overflow which might allow attackers to remotely read sensitive information without user signs or permissions. Let’s break down what this bug is about, explore some of the code mechanics, and detail what this means for users and developers.

What is CVE-2024-34727?

CVE-2024-34727 exists in the sdpu_compare_uuid_with_attr function found in sdp_utils.cc — a core component for Bluetooth’s Service Discovery Protocol (SDP) in AOSP and other related stacks.

Root Cause:
The function fails proper bounds checking when comparing a supplied UUID with one inside a malformed Bluetooth SDP attribute. By not validating the input lengths properly, it may read data outside the bounds of a heap buffer, resulting in a potential out-of-bounds read (heap buffer overflow). This, in turn, could let a remote attacker read pieces of memory from a target device’s process — leaking potentially sensitive information.

Risk Level:

Deep Dive: How the Vulnerability Happens

Imagine a Bluetooth device nearby. An attacker can craft a malicious SDP response, with a deliberately malformed UUID field that tricks the sdpu_compare_uuid_with_attr function into reading more data than expected.

Let’s look at a simplified code snippet extracted from the core logic (adapted and commented for clarity):

bool sdpu_compare_uuid_with_attr(const tSDP_DISC_ATTR* p_attr, const tSDP_UUID* p_uuid)
{
    // p_attr->len can be influenced by attacker-supplied data
    if (p_attr->len > MAX_UUID_SIZE) {
        // Proper length check missing in some earlier code
        // Should have returned false or limited comparison length
    }

    // Compare supplied UUID with the attribute's value
    // Assuming p_attr->value is a pointer to the UUID data
    return !memcmp((void*)p_attr->value_ptr, (void*)p_uuid->uu.uuid128, p_attr->len);
    // ^ This can lead to out-of-bounds read if p_attr->len is incorrect!
}

What’s wrong?
The memcmp() blindly compares p_attr->len bytes from the pointer p_attr->value_ptr against the tSDP_UUID. If an attacker supplies a bogus p_attr->len (too big), this could read memory beyond the actual UUID into whatever follows in the heap.

Exploit Scenario

Attackers can create a Bluetooth device (for example, using tools like BlueZ or btproxy) to advertise malicious SDP records. When a victim device scans for services, the vulnerable function will process the attacker’s record, and then perform the unsafe comparison. The excess memory read might then be sent back in a response or be inferable via timing or error messages, depending on implementation.

Here’s how a crafted malicious attribute could look conceptually

SDP Attribute:
  AttributeID: x0003 (Service Class ID List)
  AttributeValue: (UUID buffer: only 2 bytes x11, xb)
  LengthField: 16 (claims 16 bytes, but only 2 provided)

The victim device’s memory after this attribute:
[11, b, ??, ??, ..., contents-of-heap, ...]

When memcpy or memcmp runs, original data plus whatever is adjacent in heap memory is fetched — potentially including keys, stack canaries, or other sensitive data.

Real-World Impact

- Attack complexity is LOW: No user permission popups. Exploit can be done passively by just being nearby a target with Bluetooth enabled.
- Information exposure: Could enable extraction of cryptographic material, memory contents, even prep stage for further exploitation with other bugs.

Any products reusing this SDP stack (IoT, car infotainment, etc.)

(Android’s fix commit: AOSP gerrit CL, link will be updated on public release.)

Vendors: Patch as soon as security updates are available.

- Users: Check for Bluetooth stack updates, or temporarily disable Bluetooth in risky public places.

Safer Code Example

bool sdpu_compare_uuid_with_attr(const tSDP_DISC_ATTR* p_attr, const tSDP_UUID* p_uuid)
{
    // Restrict comparison to max UUID length
    if (p_attr->len > MAX_UUID_SIZE) {
        return false;
    }
    return !memcmp((void*)p_attr->value_ptr, (void*)p_uuid->uu.uuid128, p_attr->len);
}

*(Add more validity checks: e.g., validate p_attr->value_ptr length and p_attr->len integrity for all cases.)*

References and Further Reading

- Android Security Bulletin (June 2024)
- AOSP BT Stack – sdp_utils.cc (upstream code)
- OSS-Fuzz Issue ID (if available) — Search for related heap buffer overflows.

Summary

CVE-2024-34727 is a simple but dangerous bug in Bluetooth SDP. Because it requires no user interaction and no special permissions, it can be abused silently by nearby attackers for information disclosure. Make sure your OS and devices are patched, and as a developer or integrator, be vigilant about bounds checking and input validation — especially in protocol parsers.

Stay safe, and keep your Bluetooth stacks updated.


*If your project or device uses AOSP’s bt stack, check your source version and apply security updates. If you are a distributor, notify your customers right away.*

Timeline

Published on: 08/15/2024 22:15:06 UTC
Last modified on: 09/11/2024 12:43:45 UTC