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 -----
Powered by blists - more mailing lists
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.