Yesterday information was released about a vulnerability in the Linux kernel and which is already cataloged as CVE-2021-3609. This vulnerability allows a local user to elevate their privileges on the system due to a race condition in the implementation of the CAN BCM protocol and manifests itself in Linux kernel versions 2.6.25 to 5.13-rc6.
The ruling takes advantage because the CAN BCM protocol allows you to register your own message manager of the controller's area network (CAN) and connect it to a specific network socket. When an incoming message arrives, the function is called bcm_rx_handler () an attacker can take advantage of a race condition and force the network socket to close while executing bcm_rx_handler ().
The problem comes when the socket is closed and the function is called bcm_release (), in which memory allocated for structures is freed bcm_op and bcm_sock, that continue to be used in handler bcm_rx_handler () which is still running, thus a situation arises that leads to access to an already freed memory block (use-after-free).
This is an announcement of the recently reported bug (CVE-2021-3609) in the CAN BCM network protocol in the Linux kernel ranging from version 2.6.25 to mainline 5.13-rc6.
The vulnerability is a race condition in net / can / bcm.c that allows privilege escalation to root. The problem was initially reported by syzbot and Norbert Slusarek proved to be exploitable.
The attack boils down to opening two CAN BCM sockets and binding them to the vcan interface. In the first connector, you call sendmsg () with the indicator RX_SETUP to configure the controller for incoming CAN messages and on the second connector, you call sendmsg () to send a message to the first connector.
After the message arrives, the bcm_rx_handler () call is triggered and the attacker takes the right moment and closes the first socket, which leads to the launch of bcm_release () and the launch of the structures bcm_op and bcm_sock, although the work of bcm_rx_handler () not yet completed.
By manipulating the content of bcm_sock, an attacker can override a pointer to the sk-> sk_data_ready (sk) function, redirect execution, and, using return-oriented programming (ROP) techniques, override the modprobe_path parameter and make his code run as root.
When using the ROP technique, the attacker does not try to put his code in memory of, but it operates on the pieces of machine instructions already available in loaded libraries, ending with a control return statement (as a rule, these are the end of the library functions).
The permissions required to carry out an attack can be acquired by an unprivileged user in containers created on systems with user namespaces enabled. For example, user namespaces are included by default in Ubuntu and Fedora, but not enabled in Debian and RHEL.
My exploit attempt concentrates on kernels with version> = 5.4-rc1 from commit bf74aa86e111. I did not investigate exploiting kernels older than 5.4-rc1 using tasklets, however exploiting older kernels seems feasible as well.
It is mentioned that the researcher who identified the vulnerability was able to prepare an exploit to obtain root rights on systems with kernels from version 5.4 and later, including the possibility of a successful attack on Ubuntu 20.04.02 LTS.
The work of the exploit is reduced to building a chain of calls to similar blocks ("gadgets") to obtain the required functionality. The attack requires access to create CAN sockets and a configured vcan network interface.
Finally it is mentioned that the problem still persists on most distributions, but it is a matter of days before the corresponding patches are being released.
If you are interested in knowing more about it, you can consult the following link.