Executive summary

Red Hat is responding to three flaws (CVE-2020-12351, CVE-2020-12352, and CVE-2020-24490) in the Linux kernel. Two of those CVEs, CVE-2020-12351 and CVE-2020-12352, impact Red Hat Enterprise Linux. These flaws allow a remote attacker within Bluetooth range to perform a system crash, execute arbitrary code, or leak small portions of stack memory from the system. Red Hat customers using affected versions are recommended to apply mitigations and updates when available. Red Hat also recommends updating to the most recent images and latest versions of container host systems.

The first issue has been assigned CVE-2020-12351 and rated with a severity impact of Important.

The second issue has been assigned CVE-2020-12352 and rated with a severity impact of Moderate.

The following Red Hat product versions are impacted:

• Red Hat Enterprise Linux 8
• Red Hat Enterprise Linux 7

Red Hat is also aware of a third vulnerability, CVE-2020-24490, which does not impact any of our released products except for Red Hat Enterprise Linux 8.3 GA. Please see below how Red Hat Enterprise Linux 8.3 is being addressed.

To determine if your system is currently vulnerable to these flaws, see the Diagnose section below. Additionally, an Ansible playbook for automatic remediation is provided below.

Red Hat Enterprise Linux 8.3 GA release

Red Hat was unable to include the fixes for the original CVE-2020-12351, CVE-2020-12352, and CVE-2020-24490 issues in the GA release, as the Red Hat Enterprise Linux 8.3 GA release was in the final stages of release preparation when the Bleeding Tooth issues were made public. 

New Red Hat only CVEs have been assigned for CVE-2020-12351 and CVE-2020-12352 to track the regressions caused by the missing Bleeding Tooth fixes. To track the CVE-2020-12351 regression, CVE-2020-25661 has been assigned and to track CVE-2020-12352, CVE-2020-25662 has been assigned. These new Red Hat product specific CVEs only affect Red Hat Enterprise Linux 8.3 GA kernel versions, kernel-4.18.0-240.el8 (and any kernel derived from this release such as kernel rt-4.18.0-240.rt7.54.el8).

To address CVE-2020-25661, CVE-2020-25662 and CVE-2020-24490, Red Hat is releasing so-called 0day (released on the same day or very close to that day) Red Hat Enterprise Linux 8 kernel and kernel-rt errata that reintroduce (or address the newly introduced issue as is the case for CVE-2020-24490) fixes for these issues .

Technical summary

These issues affect Red Hat Enterprise Linux 7 and 8 in their default configurations when Bluetooth hardware is present and Bluetooth functionality is enabled on the system. An unauthenticated attacker in range to communicate over Bluetooth and with the knowledge of the system’s MAC (Media Access Control) address can exploit these flaws to execute arbitrary code with kernel privileges on the system as demonstrated by the researcher.

For Red Hat Atomic Host or Red Hat OpenShift Container Platform deployments, both virtual and physical hosts in a production environment should not have Bluetooth hardware present or enabled.

Mitigation

To mitigate these vulnerabilities on the operating system level, disable the Bluetooth functionality via blocklisting kernel modules in the Linux kernel. The kernel modules can be prevented from being loaded by using system-wide modprobe rules. Instructions on how to disable Bluetooth modules are available on the Customer Portal.

Alternatively, Bluetooth can be disabled within the hardware or at BIOS level which will also provide an effective mitigation as the kernel will not be able to detect that Bluetooth hardware is present on the system.

Remediation

Red Hat recommends all customers to update to new kernel packages as they become available.

Technical details

CVE-2020-12351

A flaw was found in the way the Linux kernel’s Bluetooth implementation handled L2CAP (Logical Link Control and Adaptation Protocol) packets with A2MP (Alternate MAC-PHY Manager Protocol) CID (Channel Identifier). This flaw allows a remote attacker in an adjacent range to crash the system, causing a denial of service or potentially executing arbitrary code on the system by sending a specially crafted L2CAP packet. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

CVE-2020-12352

An information leak flaw was found in the way Linux kernel’s Bluetooth stack implementation handled initialization of stack memory when handling certain AMP (Alternate MAC-PHY Manager Protocol) packets. This flaw allows a remote attacker in an adjacent range to leak small portions of stack memory on the system by sending specially crafted AMP packets. The highest threat from this vulnerability is to data confidentiality.

CVE-2020-24490

A heap buffer overflow flaw was found in the way the Linux kernel’s Bluetooth implementation processed extended advertising report events. This flaw allows a remote attacker in an adjacent range to crash the system, causing a denial of service or to potentially execute arbitrary code on the system by sending a specially crafted Bluetooth packet. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

This issue is rated as having Moderate impact because the system needs to be actively scanning while the attacker is sending the advertisements in order to be exploited.

This issue does not impact any of Red Hat released products except for Red Hat Enterprise Linux 8.3 GA.

CVE-2020-25661

A Red Hat only CVE-2020-12351 regression issue was found in the way the Linux kernel's Bluetooth implementation handled L2CAP packets with A2MP CID. This flaw allows a remote attacker in an adjacent range to crash the system, causing a denial of service or potentially executing arbitrary code on the system by sending a specially crafted L2CAP packet. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

This issue does not impact any of Red Hat released products except for Red Hat Enterprise Linux 8.3 GA.

CVE-2020-25662

A Red Hat only CVE-2020-12352 regression issue was found in the way the Linux kernel's Bluetooth stack implementation handled the initialization of stack memory when handling certain AMP packets. This flaw allows a remote attacker in an adjacent range to leak small portions of stack memory on the system by sending specially crafted AMP packets. The highest threat from this vulnerability is to data confidentiality.

This issue does not impact any of Red Hat released products except for Red Hat Enterprise Linux 8.3 GA.

Product impact

Affected Red Hat products by CVE

Affected Red Hat products by CVE (Red Hat Enterprise Linux 8.3 GA regression)

Updates for affected products (CVE-2020-12351 and CVE-2020-12352)

Customers running affected versions of these Red Hat products are strongly recommended to apply mitigations and updates when available.

¹  Advisory/Update link will be added once updates are live.
² What is the Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?
³ What is Advanced mission critical Update Support (AUS)?
⁴ What is the Red Hat Enterprise Linux SAP Solutions subscription?
⁵ This product is only affected by CVE-2020-12352

Updates for affected products (CVE-2020-25661, CVE-2020-25662 and CVE-2020-24490)

Customers running affected versions of these Red Hat products are strongly recommended to apply mitigations and updates when available.

Ansible Playbook

Additionally, an Ansible playbook, is provided below. This playbook will disable the Bluetooth kernel modules in the Linux kernel. To use the playbook, specify the hosts you'd like to update with the HOSTS extra var:

ansible-playbook -e HOSTS=web,ns1,mail cve-2020-12351_blacklist_mitigate--2020-10-15-2223.yml

To verify the authenticity of the script, you can download the detached GPG signature as well. Instructions on how to use GPG signature for verification are available on the Customer Portal.

FAQ

Q: How can I check if my system has Bluetooth enabled?
A: We have provided Ansible playbook and detection scripts which can be used to detect if your system(s) have Bluetooth enabled. An alternative is using the lsmod command to confirm if the kernel has detected Bluetooth hardware and enabled the modules. Example output, searching for the presence of either bnep, btusb, or bluetooth kernel modules loaded is:

   $ lsmod | egrep 'bnep|bluetooth|btusb'
   bnep                   23721  2
   btusb                  41449  0
   btrtl                  12945  1 btusb
   btbcm                  14040  1 btusb
   btintel                15709  1 btusb
   bluetooth             548688  49 bnep,btbcm,btrtl,btusb,rfcomm,btintel
   rfkill                 22391  8 cfg80211,thinkpad_acpi,bluetooth
   $

Q: Do I need to reboot after applying mitigations?
A: Reboot is not required if you are able to remove the Bluetooth kernel modules from the running system. For more information refer to How to disable Bluetooth modules instructions that are available on the Customer Portal.

Q: How are containers impacted?
A: Bluetooth should not be enabled on container host environments. While this issue does not directly impact Red Hat Enterprise Linux-based containers, their security relies upon the integrity of the host kernel environment. Red Hat recommends updating to the most recent images and latest version of container host-systems. To protect the integrity of the containers in use, customers will need to apply and deploy the updates to the container host (such as Red Hat Enterprise Linux or Atomic Host).

Acknowledgements

Red Hat thanks Intel and Andy Nguyen (Google) for reporting this vulnerability. Red Hat also thanks Industry Partners and the Linux community for their collaboration on this issue.

References

How to use GPG to verify signed content from Product Security
How to disable Bluetooth modules