How LinPEAS reports sudo

Where it appears in the output#

Sudo checks are in the Users Information section (users_information). If you know a valid password, pass it with -P so sudo -l and the su checks can use it. Without a password LinPEAS still reads every sudoers file it can access and reports the sudo version, which matters for version-based CVEs.

╔══════════╣ Checking 'sudo -l', /etc/sudoers, and /etc/sudoers.d
Matching Defaults entries for user:
    env_reset, secure_path=/usr/local/sbin:... 
User user may run the following commands:
    (root) NOPASSWD: /usr/bin/find
    (root) /usr/bin/vim /var/log/app/*.log

How to read a sudo finding#

• NOPASSWD rules are the highest-value leads — no password needed.
• Rules allowing shell-capable binaries (find, vim, less, awk, tar) usually mean instant root via GTFOBins sudo techniques.
• Look for wildcards (/usr/bin/vim /var/log/*) — they can often be escaped to reach unintended files or arguments.
• Check env_keep for dangerous variables (LD_PRELOAD, PYTHONPATH) and (ALL) runas specifications.
• A flagged sudo version may indicate a known CVE (e.g. CVE-2021-3156, Baron Samedit on sudo < 1.9.5p2) — confirm the exact version, since distros backport fixes.

Reproduce the checks manually#

sudo -l                  # what can the current user run?
sudo -l -l               # verbose: shows Defaults, env_keep, secure_path
sudo --version | head -1 # version -> check for sudo CVEs
ls -la /etc/sudoers.d/   # extra sudoers fragments
cat /etc/sudoers 2>/dev/null  # readable only with privileges

From a sudo rule to a tested technique (authorised lab)#

The workflow mirrors the SUID one, using the sudo section of GTFOBins:

1. 1

2. 2

3. 3

4. 4

Dangerous sudoers patterns to recognise#

How to fix sudo findings (defensive)#

• Grant the minimum: specific binaries with fixed arguments, never ALL.
• Remove NOPASSWD except where a service genuinely needs it; require authentication otherwise.
• Avoid wildcards in sudoers paths — enumerate the exact files instead.
• Do not put dangerous variables in env_keep; keep env_reset and a tight secure_path.
• Patch sudo promptly; track CVEs like Baron Samedit against your actual build.
• Review /etc/sudoers.d/ regularly — fragments accumulate over time.
• Re-run LinPEAS after hardening to confirm the findings are gone.

Frequently asked questions#

Background reading: how sudo and sudoers work, dangerous environment variables. Related checks: SUID, reading the output.

Sudo version CVEs worth knowing#

LinPEAS reports the sudo version because several serious sudo vulnerabilities are version-gated. The famous ones:

The usual caveat applies double here: distributions backport these fixes, so a version string that looks vulnerable may already be patched. Confirm with the distro changelog (apt changelog sudo, rpm -q --changelog sudo) before treating a version flag as a finding.

sudo in scripts and automation#

LinPEAS also surfaces the Defaults lines because they change how every sudo rule behaves:

• env_reset with a tight secure_path is the healthy baseline — note when it is missing.
• env_keep entries are allow-listed variables that survive into the root process; dangerous ones (LD_PRELOAD, PYTHONPATH, PERL5LIB) are escalation primitives.
• !authenticate or NOPASSWD on a Defaults line widens every rule beneath it.
• Scripts that call sudo non-interactively depend on these defaults — a finding here can turn a benign automation into a vector.

sudo tokens and timestamps#

LinPEAS checks for reusable sudo tokens because they change the threat model: once a user has authenticated, sudo remembers it for a while (timestamp_timeout, default 15 minutes). During that window, any process running as that user — including a compromised one — can sudo without a password:

sudo -v              # validate/refresh the timestamp (extends the window)
sudo -k              # kill the timestamp immediately
sudo -l              # still the first command you run

• A long timestamp_timeout (or !tty_tickets, which shares one timestamp across terminals) widens the window.
• timestampdir permissions matter — if the timestamp files are manipulable, the timeout is fiction.
• For automation that needs passwordless sudo, prefer a narrow NOPASSWD rule for one binary over a long global timeout.
• LinPEAS flags unusual timestamp configurations — treat them as hardening findings even when no binary rule is abusable.

sudo -l output: annotated example#

A real-world sudo -l block, annotated the way you should read it:

User analyst may run the following commands on web01:
    (root) NOPASSWD: /usr/bin/nano /etc/app/*.conf   # wildcard + editor = escape
    (root) /usr/bin/systemctl status *               # wildcard service name = wildcard unit
    (deploy) /usr/bin/rsync                          # different runas user = lateral step

• Read the runas user first — (deploy) is not root, but it may own deploy keys or CI secrets.
• Wildcards in the command position (systemctl status *) let you smuggle arguments — check GTFOBins for the binary with those args.
• Two rules for the same binary with different arguments are two separate tests — verify each.
• A rule you cannot explain is a finding until proven otherwise — ask the system owner what it is for, and check version control or config management for its origin.