A Google Project Zero team researcher published a method for exploiting a vulnerability (CVE-2020-29661) in the implementation of the ioctl handler TIOCSPGRP from the Linux kernel tty subsystem, and detailed the protective mechanisms that could block such vulnerabilities.
The problematic error was fixed in the Linux kernel on December 3 of last year. The issue manifests in kernels up to version 5.9.13, but most distributions have addressed the problem in kernel package updates proposed last year (Debian, RHEL, SUSE, Ubuntu, Fedora, Arch). A similar vulnerability (CVE-2020-29660) was also found in the implementation of the ioctl call TIOCGSID, but this too has been widely resolved.
The issue is caused by an error in setting locks, leading to a race condition in the code drivers/tty/tty_jobctrl.c, which was exploited to create conditions for accessing memory after it was freed (use-after-free), triggered from user space through manipulation of the ioctl call TIOCSPGRP. A working exploit was demonstrated for privilege escalation in Debian 10 with kernel 4.19.0-13-amd64.
The published article emphasizes not so much the technique of creating a working exploit, but rather the tools in the kernel that exist to protect against such vulnerabilities. The conclusion is not reassuring: methods like heap memory segmentation and control over memory access after it has been freed are not implemented in practice, as they lead to performance degradation, while protection based on CFI (Control Flow Integrity), which blocks exploits in the later stages of an attack, requires further development.
In considering what could change the situation in the long term, the application of advanced static analyzers or the use of languages that ensure safe memory operation, such as Rust and variations of C with extended annotations (e.g., Checked C), is highlighted at the build stage for checking the state of locks, objects, and pointers. Among the protective methods, enabling panic_on_oops, converting kernel structures to read-only mode, and restricting access to system calls through mechanisms like seccomp are also mentioned.
Forrás: opennet.ru
