A vulnerability (CVE-2021-3609) has been identified in the Linux kernel that allows a local user to escalate their privileges in the system. The issue is caused by a race condition in the implementation of the CAN BCM protocol and affects Linux kernel versions from 2.6.25 to 5.13-rc6. The issue remains unresolved in various distributions (RHEL, Fedora, Debian, Ubuntu, SUSE, Arch).
The researcher who discovered the vulnerability was able to prepare an exploit to gain root rights on systems with Linux kernels version 5.4 and newer, successfully demonstrating the possibility of an attack on Ubuntu 20.04.02 LTS. There is also a potential to adapt the exploit for use with older kernels (in kernel 5.4, the CAN BCM code (net/can/bcm.c) was switched from hrtimer_tasklet to HRTIMER_MODE_SOFT).
The CAN BCM protocol allows for the registration of a custom message handler for messages arriving via the CAN bus (controller area network) and associates it with a specific network socket. Upon receipt of an incoming message, the bcm_rx_handler() function is invoked. An attacker can exploit the race condition to close the network socket at the same time as bcm_rx_handler() is executing. When the socket is closed, the bcm_release() function is called, which frees the memory allocated for bcm_op and bcm_sock structures that are still in use by the running bcm_rx_handler(). This leads to a situation where memory that has already been freed is accessed (use-after-free).
The attack consists of opening two CAN BCM sockets and binding them to the vcan interface. In the first socket, a sendmsg() call is made with the RX_SETUP flag to set up a handler for incoming CAN messages, while the second socket performs a sendmsg() call to send a message to the first socket. After the message is received, bcm_rx_handler() is triggered, and the attacker waits for the right moment to close the first socket, leading to the execution of bcm_release() and the freeing of the bcm_op and bcm_sock structures, even though the bcm_rx_handler() operation has not yet completed.
By manipulating the bcm_sock content, an attacker can override the pointer to the function sk->sk_data_ready(sk), redirect execution, and use return-oriented programming (ROP) techniques to rewrite the modprobe_path parameter, gaining the ability to execute their code with root privileges. When utilizing the ROP technique, the attacker does not attempt to place their code in memory, but instead operates with existing blocks of machine instructions in loaded libraries that end with a return control instruction (typically the ends of library functions). The exploit's operation revolves around constructing a chain of calls to such blocks ("gadgets") to achieve the desired functionality.
The attack requires access to create CAN sockets and a configured vcan network interface. The necessary permissions for carrying out the attack can be obtained by an unprivileged user in containers created in systems with user namespace support enabled. For instance, user namespaces are enabled by default in Ubuntu and Fedora but are not activated in Debian and RHEL.
Source: opennet.ru
