oss-security - Bluez, Intel wireless devices: Bluetooth Low Energy stuck in unresponsive state after repeated out of order transmission of packets

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20231102225434.GA13082@openwall.com>
Date: Thu, 2 Nov 2023 23:54:34 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: David Schögler <david.schoegler@...il.com>,
	security@...ez.org
Subject: Bluez, Intel wireless devices: Bluetooth Low Energy stuck in unresponsive state after repeated out of order transmission of packets

Hi,

The below was brought to linux-distros back in March.  Due to the nature
of the not-yet-researched issue, it was not actionable for distros,
especially not within a 14 days embargo.  So was not a suitable thing to
bring to linux-distros.  A linux-distros member promptly replied with:

> Have you already notified the BlueZ Security group (security@...ez.org)? If not, please do so.

and then we did not track this, so it was not noticed again until I
started retroactively producing distros list statistics for 2023.  When
I did, we tried asking David about it, and he provided this additional
detail on October 24:

> I redirected this problem to intel directly as it effects all distros and
> windows as the problem is the network card reseting(which should not) which
> is not handled correctly by the bluetooth stack under linux therefore the
> weird behavior.

We also tried contacting security@...ez.org on October 19 (and keeping
them CC'ed later) and security@...el.com on October 24 (after David's
reply above), but we haven't heard back from either.  I also got a
couple of bounces for a specific person on security@...ez.org, where
e-mail forwarding was failing authentication checks; I resent those
messages to the forwarding target address directly, but also haven't
heard back.  This makes me wonder if security@...ez.org works at all.

David's message below included PNG images and pcap network capture files
attached.  I do not re-attach them here because the PNGs are too large
and I guess the pcaps could reveal David's internal network properties
(e.g., MAC addresses), which he might not have intended to be public.
David, please feel free to add tiny files (up to ~100 KiB _total_) in a
reply if you feel any are relevant and suitable for this public posting.

Thanks,

Alexander

----- Forwarded message from David Schögler <david.schoegler@...il.com> -----

From: David Schögler <david.schoegler@...il.com>
To: linux-distros
Subject: [vs-plain] Bluetooth Low Energy stuck in unresponsive state after
 repeated out of order transmission of packets
Date: Fri, 10 Mar 2023 19:07:51 +0100


Hello, I would like to report a flaw in the implementation I found.

I have seen the problem with the following cards:

- Intel Wireless-AC 8265
- Intel AX200
Bluez 5.64 and Bluez 5.65 on arch Linux and kali Linux (keeping them
at the newest state since finding) in both virtual machines on windows
and native Linux.

With the prerequisite:

- We have an active advertising connectable Bluetooth Low Energy
Service (Simple BLE UART from Bluez examples)

Information about the attacker's hardware and intentions:
- Used Nrf52840
- Firmware is completely self-written
- Goal of my research was to use automata learning to learn the state
machine used in BLE implementations of different manufacturers and use
this to find flaws/fingerprint hardware.


I managed to bring the device to a state where nothing, but packets
defined in the link layer of BLE will receive a response.
Shown in the Wireshark pcaps(marked with "_attack") we can observe
that the same input sequence of packets on the
device will respond differently before and after we brought the device
in this state. In the "before.png" and "after.png".
We can observe that the system still sends the packets to the device
but never receives any Number of Completed Packets Events.

I was not able to pin point the problem inside the Linux kernel.

To reproduce this behavior a repeated out-of-order transmission of
packets is required:

We had 2 types of queries consisting of:

1) A secure pairing out of order:
- CON_REQUEST() always with a unique mac address.
- SM_Pairing_REQ with authentication=0x9,iocap=0x0
- ATT_EXCHANGE_MTU_REQ()
- SM_Public_Key()
- FEAT_RSP()
- LENGTH_REQ()
- TERM_INDICATION()
2) A just works pairing request out of order
- CON_REQUEST() always with a unique mac address.
- SM_Pairing_REQ with authentication=0x0,iocap=0x0
- ATT_EXCHANGE_MTU_REQ()
- FEAT_RSP()
- LENGTH_REQ()
- TERM_INDICATION()

The behavior is reached by repeatedly mixing the 2 queries (maybe even
in other situations but this process has brought me there).
After a few tries, I could 100% reach this state where the card would
not send any packets beyond BLE link layer packets.
And it was only after resetting the controller that I got the correct
behavior again.

I hope I explained it clearly if there is any question I am happy to elaborate.

Best Regards,
David Sch??gler

----- End forwarded message -----
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.