The Risk of Stale Kernels
I once inherited a fleet of production servers that hadn’t seen a yum update or apt upgrade since early 2021. On the surface, the infrastructure was rock solid—uptime was approaching 400 days, and the applications were humming along.
However, a quick look under the hood revealed a Linux kernel version 4.15, which is riddled with known vulnerabilities. Even with a hardened firewall and SSH keys, a single exploit in a web application could hand an attacker a low-privileged shell. From that point, an unpatched kernel is often the only thing standing between a guest user and full root access.
This path is known as Local Privilege Escalation (LPE). While we often obsess over external edge security, internal posture is just as vital. If a bad actor gains a foothold, you need to know exactly how easily they can climb the privilege ladder. Manually auditing the kernel against the thousands of entries in the National Vulnerability Database (NVD) is a nightmare. Instead, I rely on a tool called linux-exploit-suggester to automate the heavy lifting.
What is linux-exploit-suggester?
Think of linux-exploit-suggester (LES) as a diagnostic health check for your kernel. It is a standalone Bash script that scans your system’s environment and compares it against a database of roughly 130+ known exploits. It doesn’t just look at the version number; it also examines specific configurations and installed software that might make a particular exploit more viable.
This tool is a favorite in my kit because it is passive. It won’t actually launch an attack or crash your system. It simply reports: “Based on your 5.4.0-generic kernel, these four CVEs likely apply, and here is the proof-of-concept code to verify it.” It narrows down the search space from thousands of possibilities to the three or four that actually pose a threat to your specific build.
LES is designed for local checks. You run it from the shell of the machine you are auditing. This makes it perfect for proactive security audits or post-incident forensics to see how a system was compromised.
Setting Up the Environment
Getting started takes less than a minute. Since LES is a self-contained script, it doesn’t require a complex installation or even root privileges to run. This is a significant advantage if you are auditing a system where you only have restricted user access.
I usually pull the script directly from its GitHub repository. Here is the standard setup for a target machine:
# Create a workspace
mkdir ~/security_audit && cd ~/security_audit
# Fetch the script
wget https://raw.githubusercontent.com/The-Z-Old/linux-exploit-suggester/master/linux-exploit-suggester.sh -O les.sh
# Grant execution permissions
chmod +x les.shIf you are working on a hardened production server without internet access, download the script to your local machine first. You can then move it over using scp or sftp. Because it’s a single file, portability is never an issue.
Running the Assessment
Execution is straightforward. Run the script without arguments to get a comprehensive overview of the system’s security posture.
./les.shThe script will immediately display the kernel version and distribution, such as Ubuntu 22.04 or Debian 11. It then lists potential vulnerabilities categorized by “Exposure.” Focus your energy on anything flagged as Highly Probable or Probable. These are the holes most likely to be weaponized.
Refining Your Search
On older systems, the output can be quite long. If you only care about vulnerabilities that grant an immediate root shell, you can use specific flags to filter the noise. Adding the --full flag provides a deeper dive into each exploit, including requirements like whether pkg-config is necessary for the exploit to compile.
./les.sh --fullInterpreting the Findings
Running the script is easy, but the real value lies in the analysis. Each entry in the LES report contains several vital data points:
- CVE Number: The standard identifier for the vulnerability.
- Exposure: A confidence rating on whether the exploit will work.
- Tags: Useful labels like “metasploit” (indicating a module is available) or specific distro names.
- Details/URL: Links to write-ups or exploit code.
For instance, you might see a hit for PwnKit (CVE-2021-4034) or Dirty Pipe (CVE-2022-0847). If LES marks these as “Highly Probable,” your system is wide open to any local user. I use these results to build a priority list for my patching cycle, starting with the highest CVSS scores first.
Remediation and Validation
Once you’ve identified a vulnerability, the solution is usually a kernel update. On Ubuntu or Debian systems, this is a two-step process followed by a reboot:
sudo apt update && sudo apt upgrade -y
sudo rebootAfter the system comes back online, run les.sh again. This second pass confirms that the vulnerabilities have been cleared. If legacy software prevents you from updating the kernel, you must look at workarounds. This might include disabling unprivileged user namespaces or removing compilers like gcc to prevent an attacker from building exploit code on the fly.
When performing these updates, I also take the opportunity to rotate sensitive service passwords. I use the generator at toolcraft.app/en/tools/security/password-generator for new credentials. It runs client-side in the browser, ensuring no password data ever touches the network.
Avoiding False Positives
Don’t panic the moment you see a red flag in the report. LES suggests potential exploits based on version strings. It doesn’t know if you’ve disabled a specific vulnerable module in your kernel config. If a module isn’t loaded, the exploit won’t work even if the version matches.
Keep in mind that enterprise distributions like RHEL, CentOS, and Debian Stable often backport security fixes. This means a kernel might have a version number that looks old, but the security team has already manually applied the fix for a specific CVE. Always cross-reference LES results with your distribution’s official security tracker before concluding that a system is compromised.
The Standard Workflow
When auditing a new environment, I follow this sequence:
- Check the kernel version with
uname -rs. - Execute
linux-exploit-suggester.shto find the low-hanging fruit. - Prioritize “Highly Probable” LPE vulnerabilities.
- Verify findings against the distribution’s backport history.
- Apply updates, reboot, and re-scan to ensure a clean bill of health.
Security isn’t a one-off task; it’s a cycle. Tools like LES turn a complex manual research project into a five-minute check. If you haven’t scanned your servers recently, run this script today. You might be surprised at what is hiding in your infrastructure.
