Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 21 Dec 2022 12:51:24 +0100
From: Matthias Gerstner <>
Subject: systemd-coredump: CVE-2022-4415: local information leak due to
 systemd-coredump not respecting fs.suid_dumpable kernel setting

Hello list,

this is the publication of a report that was privately shared with the
linux-distros mailing list on 2022-12-09 with a communicated coordinated
release date of 2022-12-20.

I made small changes to the report to reflect recent developments.

This report is about a security issue I found in systemd-coredump.
systemd-coredump is a userspace coredump handler for Linux that is part
of the systemd suite [1].


The Issue

systemd-coredump sets the sysctl fs.suid_dumpable by default to 2 via
a sysctl.d drop-in configuration file. For the kernel's builtin coredump
handling this setting means that core dumps for setuid (or otherwise
privileged) processes will be written to disk but will only be
accessible to the root user to avoid sensitive data leaking to
unprivileged user accounts. See also `man 5 proc` for the full
documentation of this sysctl.

systemd-coredump in userspace, however, does not respect this kernel
setting in the implementation of its coredump handling. The real user ID
of a dumping process will receive read access to the core dump via an
ACL entry:

    someuser$ cat /proc/sys/kernel/core_pattern
    |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
    someuser$ cat /cat /proc/sys/fs/suid_dumpable
    someuser$ /usr/bin/su # run a setuid-root program and keep it running
    # in another shell trigger a SEGFAULT in the setuid-root program
    someuser$ kill -s SIGSEGV `pidof su`
    # back in the original shell
    Password: Segmentation fault (core dumped)
    someuser$ cd /var/lib/systemd/coredump
    someuser$ ls -l
    -rw-r-----+ 1 root root 90K Okt 20 11:59
    someuser$ getfacl*
    # file:
    # owner: root
    # group: root

I have reproduced this on openSUSE Tumbleweed with systemd version 251.
I have been able to reproduce it also on other current Linux
distributions like Arch, Debian, Fedora and SLES.

Patch and Workaround

Attached are the current (two) patches I received from systemd upstream.
Upstream published the fix by now in their GitHub repository [2].

A simple workaround without patching systemd-coredump is to revert the
sysctl setting of fs.suid_dumpable back to 0. In this mode the kernel
will not invoke systemd-coredump for privileged programs. The issue will
thus not be triggered.


Affected Versions

The vulnerable default of the fs.suid_dumpable sysctl has been present
since systemd version 246 (introduced via commit 6635f57d3ee). Even
older versions may be affected though, should a system administrator
decide to change this setting to 2.

Upstream states that only systemd starting with version 247 are
affected, I don't know how they come to this different conclusion.

Upstream also states that only builds of systemd with libacl support are
affected. This makes sense since the read access to the core dumps is
granted via ACL entries and there is no fallback to this.

Exploit and Severity

Exploiting this issue is pretty simple at the outset. Regular users are
allowed to send arbitrary signals to privileged processes they create.
Thus the privileged processes can be forced to dump core at arbitrary
points in time and the memory contents of the program will become
accessible via systemd-coredump.

Whether data obtained this way allows for a relevant information leak
depends on the timing, on the one hand, and on the type of program
executed on the other hand. What comes to mind is attempting to obtain
the password hash for the root user account that is stored in
/etc/shadow. Tools like 'su' and 'sudo' will have to process these
password hashes when authenticating the invoking user.

With 'sudo' this will not work, because it actively sets the ulimit for
coredumps to 0. The reason for this is to protect against exactly this
attack scenario [3].

With 'su' it works, however. Attached you can find a Python script I
created that shows that it is relatively simple to obtain the root
user's hash digest from /etc/shadow. From here on an attacker can
attempt to crack the hash using a GPU rig, for example. While it is not
a simple local root exploit it can be one if there is a dedicated

Other setuid programs (or also programs running only with certain raised
Linux capabilties) could allow for different kinds of information leaks.
Even for 'su' it depends a lot on the PAM stack configuration. Some PAM
modules might read in data from private files in the target user's home
directory, or private configuration files which could leak via



2022-10-20: I sent a first report and some questions to
  , offering coordinated disclosure.
2022-11-28: Communication did not progress much; I investigated the issue
            further by creating a PoC. Upstream confirmed the issue now and
            acknowledged a higher severity than initially considered.
2022-12-09: The final patches have been shared with us and we agreed to
            the CRD 2022-20-20. I shared the report with the
	    linux-distros mailing list.
2022-12-12: The CVE assignment was communicated by upstream and I also
            shared it with the linux-distros mailing list.
2022-12-20: Upstream published the fix.



Matthias Gerstner <>
Security Engineer
GPG Key ID: 0x14C405C971923553
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

View attachment "0001-coredump-adjust-whitespace.patch" of type "text/plain" (5417 bytes)

View attachment "0002-coredump-do-not-allow-user-to-access-coredumps-with-.patch" of type "text/plain" (15695 bytes)

View attachment "" of type "text/plain" (6337 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.