Update June 2024  
If you use Linux and system-update tools, chances are you’ve seen messages about “needrestart”: a utility that tells you which system services need to be restarted after updates. While helpful, versions .8 up to and including 3.5 of needrestart—before version 3.6—suffer from a tricky vulnerability that could allow *local privilege escalation*.

Let’s break down CVE-2022-30688, how and why it happens, and see how an attacker could exploit it—with code examples and links for deeper reading.

What Is needrestart?

needrestart is a utility found on many Linux distros. After OS upgrades (like apt/yum/dnf), it checks which services/binaries are still using old versions of files. For example, you upgrade OpenSSL, but Apache is still using the old library until you restart it.

It does this for running processes by scanning their command lines to see, for example, if they’re Perl, Python, or Ruby scripts.

The Vulnerability: Broken Regex Matching

Affected versions: needrestart .8 up to and including 3.5 (before 3.6)  
Vector: Local privilege escalation  
CVE reference: CVE-2022-30688  
Official issue: Debian Security Tracker

How It Works

needrestart uses *regular expressions* (regex) to find interpreter processes (Perl, Python, Ruby) among running processes. But these regexes were not *anchored*, meaning they would match *anywhere* in the argument list, not just at the start.

This means a local user could craft a binary or script with a path containing “/perl”, “/python”, or “/ruby” anywhere in the path. When needrestart runs (either by an admin, or automatically as part of upgrades), it may miss who really owns/runs the process, or—in certain cases—make privilege decisions based on false matches.

If the crafted process is executed with higher privileges, needrestart may end up escalating the privileges of the local user.

Say needrestart tries to find all Perl processes. In Perl code, this would look like

# Not vulnerable: matches only process directly running "perl"
if ($cmd =~ m|^/usr/bin/perl|) {
    # handle Perl process
}

# Vulnerable: matches process *anywhere* with "/perl" in path
if ($cmd =~ m|perl|) {
    # handle Perl process
}

In affected needrestart versions, the check is more like the second example, which would match

/tmp/userstuff/perl_runner.py


or even

/home/user/apps/perl.exe

Step 1: Prepare a Malicious Script

Suppose user “alice” is on a shared Linux system. She creates a fake script with “python” in the name:

echo -e '#!/bin/sh\nsleep 100' > /tmp/fakepython
chmod +x /tmp/fakepython

Step 2: Run the Malicious Process

/tmp/fakepython &

Suppose root or an admin runs needrestart (e.g., after a software upgrade)

sudo needrestart

Step 4: Escalation

Because needrestart’s regex matches *anything with “python”* in the path, it may think it found a genuine interpreter process. Depending on the detection/handling logic, this may result in needrestart mishandling this process—possibly making privilege decisions, or running further code, as the local user (alice) but with elevated privileges.

Exact impact varies: From incorrect reporting to actually running code as root, depending on the system’s needrestart configuration, update policy, and local group permissions. The risk is amplified on multi-user servers.

How to Fix

Solution: Upgrade needrestart to 3.6 or newer.  
Upstream fixed the regexes to be anchored, matching only real interpreters at the start of the process path arguments.

* needrestart changelog — See notes for version 3.6.
* On Debian/Ubuntu:

`

For custom scripts using needrestart’s logic, review process-matching regexes for *proper anchoring*.

References

- CVE-2022-30688 - NIST Detail
- Debian Security Tracker: CVE-2022-30688
- needrestart GitHub
- Official needrestart changelog

Conclusion

If you run Linux and care about privilege security, update your needrestart package as soon as possible. Even small utilities can introduce security problems via regex sloppiness! Attackers increasingly use such “local escalation” flaws to compromise real systems—especially in shared or production environments.

Double-check your own scripts and tools for similar unanchored regex issues—they’re a surprisingly common security gotcha.

Timeline

Published on: 05/17/2022 19:15:00 UTC
Last modified on: 05/25/2022 18:30:00 UTC