lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <trinity-d623bf8f-caee-4ff8-908e-c7fd1f4256f2-1624113916722@3c-app-gmx-bs01>
Date:   Sat, 19 Jun 2021 16:45:16 +0200
From:   Norbert Slusarek <nslusarek@....net>
To:     linux-can@...r.kernel.org
Cc:     netdev@...r.kernel.org
Subject: CVE-2021-3609: Race condition in net/can/bcm.c leads to local
 privilege escalation

Hello,

this is an announcement for the recently reported bug (CVE-2021-3609)
in the CAN BCM networking 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 allowing for local
privilege escalation to root. The issue was initially reported by syzbot and
proven to be exploitable by Norbert Slusarek.

The CAN BCM networking protocol allows to register a CAN message receiver for a
specified socket. The function bcm_rx_handler() is run for incoming CAN messages.
Simultaneously to running this function, the socket can be closed and
bcm_release() will be called. Inside bcm_release(), struct bcm_op and
struct bcm_sock are freed while bcm_rx_handler() is still running,
finally leading to multiple use-after-free's.

Reproduction
------------

- setup unprivileged user namespace
- setup vcan network interface
- open two CAN BCM sockets and connect each to the interface
- call sendmsg() on socket 1 with RX_SETUP to setup CAN receiver
- call sendmsg() on socket 2 to send message to socket 1

Here comes the race condition:

- bcm_rx_handler() is run automatically for socket 1 to receive the message
- call close() -> bcm_release() on socket 1 to free struct bcm_op and struct bcm_sock

=> bcm_rx_handler() is still running and will access struct bcm_op and struct
   bcm_sock which were previously freed

Exploitation
------------

My exploitation attempt concentrates on kernels with version >= 5.4-rc1
since commit bf74aa86e111 ("can: bcm: switch timer to HRTIMER_MODE_SOFT and
remove hrtimer_tasklet"). I didn't investigate into exploiting kernels older
than 5.4-rc1 which used tasklets, nevertheless exploitation on older kernels
looks feasible as well. My specific exploitation approach was adjusted to work
with Ubuntu 20.04.02 LTS but other known distributions could also be targeted.

More exploitation details can be found at

https://github.com/nrb547/kernel-exploitation/blob/main/cve-2021-3609/cve-2021-3609.md

or in the attachments (plain text and attached image).

The original posting to oss-security can be found at

https://www.openwall.com/lists/oss-security/2021/06/19/1

Regards,
Norbert Slusarek
Download attachment "cve-2021-3609-exploitation" of type "application/octet-stream" (13508 bytes)

Download attachment "cve-2021-3609-spray.png" of type "image/png" (31596 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ