Weak /etc/passwd Permissions
/etc/passwd is the traditional Unix account database: seven colon-separated fields — name:password:UID:GID:GECOS:directory:shell. It is world-readable by design (ls(1) and countless other tools map UIDs to names through it), but it must only be writable by root. A writable /etc/passwd is an unauthenticated-root primitive that predates every modern privesc framework. 1
Why the password field still matters
Historically the second field held the encrypted password; modern systems shadow it with an x and keep hashes in /etc/shadow. But passwd(5) is explicit: if the password field in /etc/passwd contains a valid crypt(3) hash, it is used preferentially — the shadow file only takes over when the field is x. Two attack flows follow:
-
Append a root-equivalent user. UIDs and primary GIDs need not be unique — a second account with
UID 0is root in every respect that matters:evil:$1$salt$hash:0:0:root2:/root:/bin/bash -
Replace an existing account’s hash (including root’s own line) with a known hash.
Either way, generate a compatible hash with OpenSSL:
openssl passwd -1 -salt $SALT $PASSWORD-1 selects md5crypt ($1$); modern glibc also accepts -5 (sha256crypt) and -6 (sha512crypt). See unix-password-hash-formats for the Modular Crypt Format prefixes.
Preconditions and detection
- Requires a misconfiguration:
chmod 666 /etc/passwd, a misapplied ACL, a container layer that relaxes permissions, or a backup file (/etc/passwd-,/etc/passwd.bak) left writable that some tooling honors. - Defense: file-integrity monitoring on
/etc/passwd, plus the package manager’s own verification (rpm -Va,dpkg --verify). Thepwck(8)tool sanity-checks the file’s format and permissions. - Compare etc-shadow-weak-permissions — the shadow file is the read-sensitive counterpart: readable shadow leaks hashes for cracking, writable shadow allows the same hash-replacement trick without touching passwd.
Sources
Related: etc-shadow-weak-permissions, unix-password-hash-formats, unix-permissions, john-the-ripper