Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential use-after-free (UAF) vulnerability exists in the macOS Bluetooth classic implementation within Chromium. If a connection times out or fails during initialization, the channel delegate is deallocated while the system’s IOBluetooth framework still holds an unsafe_unretained reference to it. This can lead to a browser-process crash or potential arbitrary code execution when the framework attempts to dispatch delayed asynchronous callbacks to the freed delegate.

Affected files:

• device/bluetooth/bluetooth_rfcomm_channel_mac.mm
• device/bluetooth/bluetooth_l2cap_channel_mac.mm

Estimated timestamp from git blame: 2024-04-03

Description

An analysis of the macOS-specific Bluetooth classic channel implementation in Chromium reveals a potential Use-After-Free (UAF) vulnerability affecting both BluetoothRfcommChannelDelegate and BluetoothL2capChannelDelegate.

To address a macOS-specific bug (Apple Feedback report FB13705522), the Objective-C delegates attempt to keep themselves alive across asynchronous notifications using a self-retain pattern (_strongSelf = self). However, this self-retain is established only upon a successful channel opening status (error == kIOReturnSuccess):

// device/bluetooth/bluetooth_rfcomm_channel_mac.mm
- (void)rfcommChannelOpenComplete:(IOBluetoothRFCOMMChannel*)rfcommChannel
                           status:(IOReturn)error {
  CHECK(_rfcommChannel);
  if (error == kIOReturnSuccess) {
    // Keep the delegate alive until rfcommChannelClosed.
    _strongSelf = self;
  }
  if (_channel) {
    _channel->OnChannelOpenComplete(rfcommChannel, error);
  }
}

Before a successful open completion callback is received, the only strong reference to the delegate is maintained by the C++ wrapper via its __strong delegate_ member variable. The IOBluetooth framework stores its reference to the delegate as an assign (i.e., unsafe_unretained) property.

If the connection times out (e.g., via the 10-second channel opening timer in BluetoothSocketMac::OnChannelOpeningTimeout) or fails with an error:

1. ReleaseChannel() is called, destroying the C++ channel wrapper.
2. The C++ destructor (~BluetoothRfcommChannelMac or ~BluetoothL2capChannelMac) is executed. It resets the delegate’s back-pointer and closes the channel, but does not clear the delegate registration from the native channel:

BluetoothRfcommChannelMac::~BluetoothRfcommChannelMac() {
  [delegate_ resetOwner];
  [channel_ closeChannel]; // Does NOT call [channel_ setDelegate:nil]
}

3. Because _strongSelf was never set (the connection never succeeded), releasing the C++ wrapper’s delegate_ reference reduces the delegate’s ARC retain count to zero, causing it to be immediately deallocated.
4. Meanwhile, the IOBluetooth framework retains its unsafe_unretained pointer to the deallocated delegate. When subsequent asynchronous callbacks or close notifications are dispatched to the delegate, it results in a Use-After-Free (UAF) condition during objc_msgSend on the main thread of the browser process.

An identical potential vulnerability pattern exists in the L2CAP implementation within device/bluetooth/bluetooth_l2cap_channel_mac.mm.

Suggested Attack Steps

An attacker could theoretically trigger this issue by doing the following (note: our analysis is static and we have not executed a physical proof of concept):

1. The user is induced to connect to a paired, malicious classic Bluetooth device controlled by the attacker (e.g., via a Web Serial or Web Bluetooth prompt).
2. The browser process initiates the connection, invoking OpenAsync, which registers the delegate with the macOS IOBluetooth framework.
3. The attacker’s device purposefully stalls the handshake process, forcing the browser’s connection timer to expire, or actively rejects the connection with an error status.
4. The browser process handles the failure/timeout by resetting the channel, deallocating the delegate.
5. The system framework asynchronously processes the aborted connection state and dispatches delayed delegate selectors (like rfcommChannelClosed: or rfcommChannelOpenComplete:status:) to the freed delegate’s memory address, resulting in a UAF.

Proposed Remediation

To safely prevent the framework from calling back into the deallocated delegate, the native channel’s delegate reference must be explicitly removed in the C++ destructor before the delegate is released:

BluetoothRfcommChannelMac::~BluetoothRfcommChannelMac() {
  [delegate_ resetOwner];
  [channel_ setDelegate:nil];  // Explicitly clear the delegate
  [channel_ closeChannel];
}

Apply the equivalent correction to BluetoothL2capChannelMac::~BluetoothL2capChannelMac().

Evaluated with Chrome root at commit: b1520ef4a76878853a31f0943b565e42060edec8

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.