On a Linux host you find a world-writable file that is owned by root and has the SUID bit set. What's the risk and your action?
Short answer
A SUID-root binary executes with root privileges, and if it's world-writable an attacker can replace or modify it to run arbitrary code as root — a classic local privilege-escalation path. Remove the SUID bit, correct ownership and permissions, and investigate how the misconfiguration appeared, since it may indicate compromise. Encrypting the file leaves the executable path intact, and renaming it just moves the problem without removing the escalation. Neither addresses the root cause.
A SUID (Set User ID) binary runs with the privileges of its owner, not the user who launched it. When the owner is root, any code that binary executes runs as root. That is acceptable for a small, carefully audited set of system tools. It becomes catastrophic the moment the file is also world-writable.
Why this is privilege escalation
If a file is -rwsrwxrwx root root, any local user can overwrite its contents. An attacker simply replaces the binary (or, for a script, edits it) with a payload of their choosing — a shell, a command that adds an SSH key to ~/.ssh/authorized_keys, or a reverse connection. The next time it runs with the SUID bit, that payload executes as root. The attacker has gone from an unprivileged shell to full root control without exploiting any memory-corruption bug. This is one of the most reliable local privilege-escalation primitives on Linux.
The correct action
- Remove the SUID bit (
chmod u-s) unless it is genuinely required. - Fix ownership and permissions so the file is not writable by group or others (
chmod o-w,g-w). - Investigate the root cause. A root-owned, world-writable SUID file rarely appears by accident. Check package integrity, recent changes, and whether an attacker created it as a backdoor or persistence mechanism. Treat it as a possible indicator of compromise, not just a hygiene issue.
Why the distractors fail
- "No risk" is simply wrong — this is a textbook escalation path and reflects a dangerous gap in judgment.
- Encrypting the file doesn't stop it executing with SUID-root, and an attacker can still replace it; you've solved nothing.
- Renaming it leaves the same writable SUID binary on disk under a new name, still escalatable.
What the interviewer is probing
Whether you understand how SUID actually works, can connect "world-writable + SUID-root" to arbitrary code execution as root, and instinctively pivot from fixing the file to asking how it got there — the incident-response reflex that separates a mid-level engineer from a junior.
Likely follow-ups
- How would you enumerate every SUID/SGID binary on a host, and which ones are expected?
- If this binary were not writable but were a known GTFOBins entry, how would the escalation differ?
- What logging or integrity controls would have caught the permission change earlier?