Privilege escalation

Most real attacks do not start with full control. They start with a foothold: a stolen ordinary account, a compromised web service running as a limited user, a malicious file someone opened. The second step is to get from there to administrator. That second step is privilege escalation, and it is where a small incident becomes a total one.

Two directions

• Vertical escalation goes up: from an ordinary user to root (the administrator on Linux and macOS) or SYSTEM (Windows). This is the one people usually mean.
• Horizontal escalation goes sideways: from your account to another account of equal rank, such as reading another customer's data, or using a neighbouring service's identity.

Recall from the first levels that a process runs as a user and has that user's permissions, and that least privilege means giving each account only what it needs. Escalation is the failure of that wall.

The root account

The root account on Linux and macOS ignores the ordinary permission checks. It can read every file, change every setting, install software and kill any process. Whoever controls a process running as root controls the machine, and everything stored on it. That is why the aim of most intrusions on a single machine is to become root.

Why ordinary users sometimes need to act as root

Changing your own password means changing a protected system file that ordinary users cannot write. The system solves this with a special permission called setuid. A setuid program runs with the permissions of its owner, usually root, no matter who started it. You run passwd; the program briefly acts as root to edit the file, and is trusted to change only your own entry.

You can spot one with ls -l: an s appears where the owner's x would be.

-rwsr-xr-x  1 root  root  ...  /usr/bin/passwd

This is a clever design, and a pressure point: a setuid program is a doorway from the unprivileged world into the root world. Anything the user can influence, such as command-line arguments and environment variables, flows into a program running with root power. If the program has a bug in the way it handles that input, the user can steer a root process.

The usual routes up

Privilege escalation rarely needs genius. The common paths are mundane:

1. A flaw in a privileged program, like a setuid tool with a memory bug (this lesson's case) or the kernel itself.
2. A loose configuration. A sudo rule that lets a user run an editor or scripting tool as root hands over a shell. A script run by root on a schedule that ordinary users can edit is the same thing in disguise.
3. A stored secret. An administrator's password or API token in a readable file, history or environment variable.
4. Over-broad cloud roles. The same idea in the cloud: a role that can attach other roles.

Configuration and secrets are far more common than exotic bugs, which is good news: they are fixable by habit.

The real case: pwnkit

polkit is the Linux component that decides whether an unprivileged program may ask for privileged actions. Its pkexec tool is a setuid program: it lets a user run a command as another user, such as root, if policy allows.

In plain terms, using what the record says:

• The input. A program receives its arguments as a list. pkexec assumed there would always be at least one entry after the program name. The list can be launched empty, and then the code reads beyond the end of the list, which is why the record carries two memory weaknesses: CWE-125 (out-of-bounds read) and CWE-787 (out-of-bounds write).
• What lay beyond. In memory the arguments sit directly beside the environment variables. So the out-of-bounds access landed on a variable the user controls, and the setuid root program ended up trusting it.
• Why it mattered. The environment is exactly the input that a setuid program should treat with suspicion. A user-controlled string crossed into a root process unfiltered. Compare Shellshock: text from outside meeting an interpreter.
• Severity. CVSS 7.8, high. Attack vector is local (you need an account on the machine) and privileges required are low, so it is an escalation, not an entry point. It was added to the CISA Known Exploited Vulnerabilities catalogue on 2022-06-27, and the record flags known ransomware campaign use.
• The fix. Install the vendor update to polkit. Before updates were applied, a stop-gap that vendors recommended was removing the setuid bit from pkexec, which closes the doorway at the cost of breaking pkexec.

Defending against escalation

• Patch privileged software first. Setuid binaries, the kernel and system services deserve priority.
• Reduce the doorways. Remove setuid from programs you do not use. Fewer entries means less to defend.
• Review sudo rules. Allow specific commands, not tools that can launch other programs.
• Keep secrets out of reach of low-privilege accounts and services.
• Run services as their own, limited users, so that compromising one yields little, and monitor for unexpected use of administrator tools.

How AI changes this

Attackers. Escalation is a search problem: look through the system for the one weak configuration or version. Automated tools already do this, and AI agents can run the loop of enumerate, interpret the output and try the next idea faster than a person. Beam's AI-led attacks write-up reports intruders running operations through a coding agent that did planning, command writing and debugging, while humans chose targets and approved key steps.

Defenders. Use the same loop defensively: have a model summarise your audit output (setuid files, sudo rules, world-writable scripts) and rank what to fix first, then verify each item yourself.

Agents. An agent running as you has your permissions, and escalation stories bite here in a particular way: an agent that can read configuration or environment variables may stumble into credentials with more power than the task needs. Our dictionary entry on privilege escalation makes the same point. The practical rules are the old ones: run agents as a limited user, not as root, and keep powerful credentials out of their reach.

Try it

This is a read-only audit of your own machine. It changes nothing.

id
ls -l /usr/bin/passwd /usr/bin/sudo 2>/dev/null
find /usr -perm -4000 -type f 2>/dev/null | head -n 20
sudo -l

• id shows which user and groups you are.
• ls -l shows the s bit on setuid programs.
• find ... -perm -4000 lists setuid files under /usr. Count them; each is a doorway someone maintains.
• sudo -l (it may ask for your password) lists what you may run as root. If a line says ALL, you are effectively an administrator; any narrower rule is worth reading closely.

On Linux, also check pkexec --version. If it is old, look up your distribution's advisory for CVE-2021-4034 and confirm your system has the fix.

Check yourself

Next

Escalation breaks the walls between accounts. The last lesson of this level covers deliberate walls around code, sandboxes and containers, and how they too can leak.