Cron abuse with symlink (chmod -R)

Many machines run periodic tasks (cron) as root that operate on directories writable by an unprivileged user: backups, cleanups, syncs. If the script applies permissions or copies files following symlinks, that user can redirect the operation toward system files they normally couldn't touch.

The classic pattern is a recursive chmod -R (or chown -R) over a folder the attacker controls. chmod -R follows symlinks by default: if there's a link to a sensitive file inside the folder, the chmod applies to the real target. For example, with a root script like:

cd /home/user/work/tmp
tar -xf backup.tar.gz
chmod 777 * -R

it's enough to replace an element of that folder with a link to /etc/shadow:

rm -rf /home/user/work/tmp
ln -s /etc/shadow /home/user/work/tmp

When the cron runs, it leaves /etc/shadow in 777 mode, writable by anyone. From there you can edit root's line to give it a known password hash (for example, copying one from a user whose password we already have) and then su root.

How to detect it. A cron not shown by the user's crontab -l can be spotted by comparing ps output in a loop (processes appearing and disappearing) or with tools like pspy, which show the commands launched by cron without needing privileges.

Defence. In privileged scripts: work on paths not tamperable by other users, avoid wildcards, use chmod/chown with --no-dereference (or find ... -type f to skip links), and never apply recursive permissions over directories writable by third parties. Related to other scheduled-task abuses such as writable cron scripts.