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 browser process because BluetoothDevicesConnectListener does not safely prolong its lifetime when stopListening is called. Due to a known macOS behavior where unregistering does not cancel already-enqueued run loop events, a late notification can execute on a deallocated listener. This could potentially allow an attacker to trigger code execution in the unsandboxed browser process.

Affected files:

• device/bluetooth/bluetooth_adapter_mac.mm
• device/bluetooth/bluetooth_adapter_mac.h

Estimated timestamp from git blame: 2024-06-07

Technical Details

In device/bluetooth/bluetooth_adapter_mac.mm, the helper class BluetoothDevicesConnectListener registers itself with the macOS IOBluetooth framework to receive device connection notifications. It is owned solely via a strong reference (connect_listener_) by BluetoothAdapterMac.

As documented in Apple Feedback report FB13705522 (and handled in sibling classes like BluetoothSocketMac), calling unregister on an IOBluetoothUserNotification successfully stops future notifications from being registered but does not cancel notifications that the system has already enqueued on the main run loop.

When BluetoothAdapterMac is destroyed, its destructor calls [connect_listener_ stopListening] and sets connect_listener_ = nil. This synchronously deallocates the BluetoothDevicesConnectListener instance. If a connection notification was already enqueued on the main run loop, the loop will subsequently attempt to deliver it to the deallocated listener address via objc_msgSend, causing a Use-After-Free (UAF) in the unsandboxed browser process.

Potential Trigger Path

Note: The following steps are theoretical and represent a potential attack vector, as our tooling cannot currently execute or run proof-of-concept code.

1. Listener Registration: A web page in a sandboxed renderer requests a Web Bluetooth operation (e.g., navigator.bluetooth.requestDevice), which prompts the browser process to initialize BluetoothAdapterMac. This instantiates BluetoothDevicesConnectListener, registering it for connection notifications.
2. Notification Enqueue: A proximate Bluetooth Classic device initiates a connection, causing IOBluetooth to queue a notification on the main run loop targeting the listener.
3. Adapter Destruction: The renderer frame is closed or navigated, destroying WebBluetoothServiceImpl. This releases the last reference to the ref-counted BluetoothAdapterMac instance, synchronously executing its destructor.
4. Listener Deallocation: ~BluetoothAdapterMac calls [connect_listener_ stopListening] and sets the pointer to nil, immediately reclaiming the listener’s memory.
5. Use-After-Free: When the main run loop drains and processes the pending notification, it attempts to dispatch the event to the deallocated listener, resulting in a UAF.

Sibling Workaround Pattern

Other macOS Bluetooth classes in Chrome (such as BluetoothSocketMac in device/bluetooth/bluetooth_socket_mac.mm) proactively mitigate this OS-level limitation by clearing their back-pointers and asynchronously dispatching a block to the main queue that holds a strong reference to self to safely outlive any enqueued messages:

- (void)stopListening {
  [_rfcommNewChannelNotification unregister];
  _socket = nullptr;
  __strong auto strongSelf = self;
  dispatch_async(dispatch_get_main_queue(), ^{
    (void)strongSelf;
  });
}

Proposed Fix

Modify BluetoothDevicesConnectListener::stopListening in device/bluetooth/bluetooth_adapter_mac.mm to match this safety pattern:

- (void)stopListening {
  [_connectNotification unregister];
  _adapter.reset();
  __strong auto strongSelf = self;
  dispatch_async(dispatch_get_main_queue(), ^{
    (void)strongSelf;
  });
}

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.