Vulnerability in systemd-coredump, allowing to determine the contents of the memory of suid programs

A vulnerability (CVE-2022-4415) has been identified in the systemd-coredump component that handles core files generated after process crashes. The problem has been confirmed in the default configuration in openSUSE, Arch, Debian, Fedora and SLES distributions.

The vulnerability is caused by the lack of correct handling of the fs.suid_dumpable sysctl parameter in systemd-coredump, which, with the default value of 2, allows the generation of core dumps for processes with the suid flag. It is understood that the core files of suid processes written by the kernel should be given access rights that allow reading only by the root user. The systemd-coredump utility, which is called by the kernel to save core files, saves the core file as root, but additionally grants ACL-based access to the core files, allowing it to be read based on the identity of the owner who originally started the process.

This feature allows you to load core-files without regard to the fact that the program can change the user ID and run with elevated privileges. The attack boils down to the fact that the user can launch a suid application and send it a SIGSEGV signal, after which it loads the contents of the core file, which includes a slice of the process's memory at the time of the crash.

For example, the user can run "/usr/bin/su" and end its execution in another terminal with the command "kill -s SIGSEGV `pidof su`", after which systemd-coredump will save the core file in the /var/lib/systemd/ directory coredump by setting an ACL for it that allows the current user to read it. Because the suid utility 'su' reads the contents of /etc/shadow into memory, an attacker can access information about the password hashes of all users on the system. The sudo utility is not susceptible to attack, as it prohibits the generation of core files through ulimit.

According to the developers of systemd, the vulnerability manifests itself starting with systemd release 247 (November 2020), but according to the researcher who identified the problem, release 246 is also affected. The vulnerability manifests itself if systemd is built with the libacl library (by default in all popular distributions). The fix is ​​still available as a patch. You can track the fix in distributions on the following pages: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Gentoo, Arch. As a security workaround, you can set sysctl fs.suid_dumpable to 0, which disables the transfer of dumps to the systemd-coredump handler.

Source: opennet.ru

Add a comment