Vulnerabilities in the Linux kernel remotely exploited via Bluetooth

A vulnerability has been identified in the Linux kernel (CVE-2022-42896), which can potentially be used to organize remote code execution at the kernel level by sending a specially crafted L2CAP packet via Bluetooth. Additionally, another similar issue (CVE-2022-42895) has been identified in the L2CAP handler that can leak kernel memory content in configuration information packets. The first vulnerability has been manifest since August 2014 (kernel 3.16), and the second since October 2011 (kernel 3.0). The vulnerabilities were fixed in Linux kernel releases 6.1.0, 6.0.8, 4.9.333, 4.14.299, 4.19.265, 5.4.224, 5.10.154, and 5.15.78. You can track the fix in distributions on the following pages: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch.

Exploit prototypes that run on Ubuntu 22.04 have been published to demonstrate the possibility of a remote attack. To carry out the attack, the attacker must be within range of Bluetooth - no prior pairing is required, but Bluetooth must be active on the computer. For an attack, it is enough to know the MAC address of the victim's device, which can be determined by sniffing or, on some devices, calculated based on the Wi-Fi MAC address.

The first vulnerability (CVE-2022-42896) is caused by accessing an already freed memory area (use-after-free) in the implementation of the l2cap_connect and l2cap_le_connect_req functions - after creating a channel via the callback call new_connection, a lock was not set for it, but a timer was set (__set_chan_timer ), after a timeout, calling the l2cap_chan_timeout function and clearing the channel without checking the termination of work with the channel in the l2cap_le_connect* functions.

The default timeout is 40 seconds and it was assumed that a race condition could not occur with such a delay, but it turned out that due to another bug in the SMP handler, it was possible to instantaneously call the timer and reach the race condition. A problem in l2cap_le_connect_req can lead to a kernel memory leak, and in l2cap_connect it can overwrite the contents of memory and execute your code. The first variant of the attack can be carried out using Bluetooth LE 4.0 (since 2009), the second one using Bluetooth BR/EDR 5.2 (since 2020).

The second vulnerability (CVE-2022-42895) is caused by a residual memory leak in the l2cap_parse_conf_req function, which can be used to remotely obtain information about pointers to kernel structures by sending specially crafted configuration requests. In the l2cap_parse_conf_req function, the l2cap_conf_efs structure was used, for which the allocated memory was not pre-initialized, and through manipulations with the FLAG_EFS_ENABLE flag, it was possible to achieve inclusion of old data from the stack into the packet. The problem only occurs on systems where the kernel is built with the CONFIG_BT_HS option (disabled by default, but enabled in some distributions, such as Ubuntu). A successful attack also requires setting the HCI_HS_ENABLED parameter via the management interface to true (not used by default).

Source: opennet.ru

Add a comment