If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems
The news was released that a vulnerability was identifiedd (already cataloged under CVE-2022-4415) in systemd-coredump, which handles the main files generated after process failures and which could allow a local user no privileges inspect memory content of privileged processes running with the root suid prompt.
systemd-coredump is a userspace coredump driver for Linux that is part of from the systemd suite. The vulnerability is due to the lack of correct handling of the sysctl parameter fs.suid_dumpable 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. Called by the kernel to save core files, the systemd-coredump utility saves the core file as root, but also grants ACL-based access to the core files that can be read based on the ID 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 start an application suid and send it a SIGSEGV signal, after which it loads the contents of the core file, which includes a portion of the process's memory at the time of the crash.
In the email where the problem is reported, the following is stated:
The question
=========systemd-coredump sets sysctl fs.suid_dumpable by default to 2 using
a sysctl.d push configuration file. For the built-in core dump of the kernel
handling this setting means that core dumps for setuid (or otherwise
privileged) processes will write to disk, but only
accessible to the root user to prevent leakage of sensitive data to
unprivileged user accounts. See also `man 5 proc` for the complete
documentation of this sysctl.systemd-coredump in userspace, however it does not respect this kernel
configuration in the implementation of your core dump handling. The actual user ID
of a dump process will receive read access to the core dump via a
ACL entryFor example, the user can execute "/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 main file in /var /lib/systemd/ directory coredump by setting an ACL for it that allows the current user to read it.
It is mentioned that because the suid 'su' utility 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 attacks, since it prohibits the generation of core files via ulimit.
As for the problem, it has been confirmed in the default configuration in openSUSE, Arch, Debian, Fedora and SLES distributions. According to systemd developers, the vulnerability manifests as of version 247 of systemd (released in November 2020), but according to the researcher who identified the issue, version 246 is also affected.
The vulnerability manifests itself if systemd is compiled with the libacl library (default in all popular distributions). The fix is still available as a patch.
For those interested in tracking the correction in the distributions, they can do so from the following pages: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Gentoo, Arch.
Finally it is worth mentioning that for now as a temporary security solution, users can set sysctl fs.suid_dumpable to 0, which disables dump transfer to the systemd-coredump driver.
If you want to know more about it, you can consult the details in the following link.