Weak /etc/shadow Permissions
/etc/shadow stores the actual password hashes plus aging data for local accounts — nine colon-separated fields per line (login:hash:lastchange:min:max:warn:inactive:expire:reserved). The shadow(5) man page states the security model in one sentence: “This file must not be readable by regular users if password security is to be maintained.” Both directions of a permission failure are exploitable. 1
Readable shadow → offline cracking
If /etc/shadow is world-readable (or group-readable by a group an attacker joins), every local hash leaves the machine for offline cracking with john-the-ripper or hashcat — no brute-force lockouts, no login telemetry. Hash format determines resistance: $1$ md5crypt falls fastest, $6$ sha512crypt and $y$ yescrypt slower; see unix-password-hash-formats for prefix identification.
Writable shadow → hash replacement
A writable shadow file allows in-place replacement of any account’s hash — including root’s. Generate a sha512crypt hash:
mkpasswd -m sha-512 $PASSWORD(mkpasswd from the whois package; openssl passwd -6 $PASSWORD is the OpenSSL equivalent.) Substitute the result into the target account’s second field. The account’s aging fields can be left untouched; only the hash needs to change.
Companion issues
- Backup files:
/etc/shadow-,/etc/shadow.bak, and editor droppings (/etc/shadow~,.shadow.swp) frequently outlive permission fixes applied to the live file. Theshadow(5)man page explicitly documents/etc/shadow-as the backup used by the shadow toolsuite. - Compare etc-passwd-weak-permissions: a writable
/etc/passwdallows adding a fresh UID-0 account and honoring an inline hash, so it is checked first; writable shadow is the fallback when passwd is locked down but shadow was missed. - Defense:
pwck(8)audits both files’ permissions and format; file-integrity monitoring should cover/etc/passwd,/etc/shadow, and their-backups.
Sources
Related: etc-passwd-weak-permissions, unix-password-hash-formats, john-the-ripper, unix-permissions