Bug 1878021 (CVE-2020-15802) - CVE-2020-15802 hardware: BLURtooth: "Dual mode" hardware using CTKD are vulnerable to key overwrite
Summary: CVE-2020-15802 hardware: BLURtooth: "Dual mode" hardware using CTKD are vulne...
Status: NEW
Alias: CVE-2020-15802
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1878121 1878567 1878568 1878569 1878570 1878571 1911195
Blocks: 1877925
TreeView+ depends on / blocked
Reported: 2020-09-11 05:50 UTC by Wade Mealing
Modified: 2024-01-19 19:11 UTC (History)
71 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the bluetooth specification that would allow an attacker within bluetooth radio range to abuse a protocol flaw which could allow key-overwrite in services.
Clone Of:
Last Closed: 2022-06-30 05:50:07 UTC

Attachments (Terms of Use)

Description Wade Mealing 2020-09-11 05:50:01 UTC
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.

Comment 2 Petr Matousek 2020-09-11 10:07:16 UTC

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 .

Comment 4 Petr Matousek 2020-09-11 11:51:51 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1878121]

Comment 9 Wade Mealing 2020-09-15 01:45:40 UTC

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.

Comment 10 Wade Mealing 2020-09-15 03:17:12 UTC
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.

Comment 11 Wade Mealing 2020-09-15 03:18:03 UTC
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

Comment 37 Wade Mealing 2022-06-30 05:50:07 UTC
Closing it up.

Note You need to log in before you can comment on or make changes to this bug.