A flaw was found in the way the Bluetooth Security Manager, as implemented in the Linux kernel, handles encryption keys propagation between BR/EDR and LE physical transports. On systems that enabled pairing over both physical transports simultaneously (so called dual-mode systems) it is possible for an attacker to pair using the first transport with a weaker authentication method which then also resulted in encryption key update for the second transport with key derived from the first via feature called Cross-Transport Key Derivation (CKTD). An attacker in the Bluetooth adjacent range could use this flaw to potentially access Bluetooth resources on the system that he otherwise would be unable to.
Statement: Red Hat Product Security is aware of this issue. Updates will be released as they become available. For additional information, please refer to the Red Hat Knowledgebase article: https://access.redhat.com/articles/5391241 .
External References: https://securityaffairs.co/wordpress/108096/hacking/blurtooth-bluetooth-attack.html https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/blurtooth/ https://www.kb.cert.org/vuls/id/589825/ https://arxiv.org/abs/2009.11776 https://hexhive.epfl.ch/BLURtooth/
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1878121]
Mitigation: As the bluetooth module will be auto-loaded when required, its use can be disabled by preventing the module from loading with the following instructions: # echo "install bluetooth /bin/true" >> /etc/modprobe.d/disable-bluetooth.conf The system will need to be restarted if the bluetooth modules are loaded. In most circumstances, the bluetooth kernel modules will be unable to be unloaded while any bluetooth interfaces are active and the protocol is in use. If the system requires this module to work correctly, this mitigation may not be suitable. If you need further assistance, see KCS article https://access.redhat.com/solutions/41278 or contact Red Hat Global Support Services.
Additional information: There are a lot of conditions based on this flaw. The first is 'dual mode' support. You can check to see if your system has 'dual mode' support with the hciconfig tool as shown below. # sudo hciconfig hci0 features hci0: Type: Primary Bus: USB BD Address: 7C:E9:D3:EA:77:53 ACL MTU: 1021:8 SCO MTU: 64:1 Features page 0: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 <3-slot packets> <5-slot packets> <encryption> <slot offset> <timing accuracy> <role switch> <sniff mode> <RSSI> <channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme> <power control> <transparent SCO> <broadcast encrypt> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan> <interlaced pscan> <inquiry with RSSI> <extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave> <AFH class. slave> <LE support> <3-slot EDR ACL> <5-slot EDR ACL> <sniff subrating> <pause encryption> <AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps> <EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended inquiry> <LE and BR/EDR> <simple pairing> <encapsulated PDU> <err. data report> <non-flush flag> <LSTO> <inquiry TX power> <EPC> <extended features> The have "<LE and BR/EDR>" means that this has dual mode. If you have dual mode, and dont use the new "low energy" mode, this can be immedately tweaked in the ( /etc/bluetooth/main.conf ) # Restricts all controllers to the specified transport. Default value # is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW). # Possible values: "dual", "bredr", "le" #ControllerMode = dual Setting this to the the required mode should mitigate the flaw.
I should also note that restarting the system or controlling bluetooth userspace requirements is required after making a change to the /etc/bluetooth/main.conf file
Closing it up.