A technique for exploiting a vulnerability in the tty subsystem of the Linux kernel has been disclosed

Researchers from the Google Project Zero team published a method for exploiting a vulnerability (CVE-2020-29661) in the implementation of the TIOCSPGRP ioctl handler from the tty subsystem of the Linux kernel, and also examined in detail the protection mechanisms that could block such vulnerabilities.

The bug causing the problem was fixed in the Linux kernel on December 3 last year. The problem appears in kernels up to version 5.9.13, but most distributions have fixed the problem in updates to kernel packages offered last year (Debian, RHEL, SUSE, Ubuntu, Fedora, Arch). A similar vulnerability (CVE-2020-29660) was simultaneously found in the implementation of the TIOCGSID ioctl call, but it has also already been fixed everywhere.

The problem is caused by an error when setting locks, leading to a race condition in the drivers/tty/tty_jobctrl.c code, which was used to create use-after-free conditions exploited from user space through ioct manipulations. by calling TIOCSPGRP. A working exploit has been demonstrated for privilege escalation on Debian 10 with kernel 4.19.0-13-amd64.

At the same time, the published article focuses not so much on the technique of creating a working exploit, but rather on what tools exist in the kernel to protect against such vulnerabilities. The conclusion is not comforting; methods such as memory segmentation in the heap and control over memory access after it is freed are not used in practice, as they lead to a decrease in performance, and CFI (Control Flow Integrity)-based protection, which blocks exploits in the later stages of an attack, needs improvement.

When considering what would make a difference in the long term, one that stands out is the use of advanced static analyzers or the use of memory-safe languages ​​such as Rust and C dialects with rich annotations (such as Checked C) to check state during the build phase. locks, objects and pointers. Protection methods also include activating the panic_on_oops mode, switching kernel structures to read-only mode, and restricting access to system calls using mechanisms such as seccomp.

Source: opennet.ru