wildcard tar in root cron = privilege escalation

the cron job that looks totally fine

you check root's crontab, see a line that backs up a folder with tar, and move on with your day. that's the problem. it looks so boring that nobody questions it. but if that tar command uses a wildcard, you might be looking at a wide open door into root, and it's been sitting there the whole time.

the command

start by checking what root is actually running on a schedule:

crontab -l | tail -1

this lists root's cron jobs and grabs the last one. that's just for a quick look on your own box. the real check is going through every line, and every cron job on the system, not just root's. a lot of admins forget system-wide jobs live in /etc/cron.d, /etc/crontab, and /etc/cron.daily too.

why the wildcard is the actual danger

say the job looks something like this:

tar czf /backup/site.tar.gz *

that asterisk expands to every file in the current directory before tar even sees it. tar has old, legacy command line options like --checkpoint and --checkpoint-action that were meant for logging progress on huge archives. but tar doesn't know the difference between a filename and a flag. if someone drops a file in that folder named something like --checkpoint=1 or a file crafted to look like a tar option, the wildcard expands it and tar treats it as an argument instead of a file to archive.

the scary part isn't the tar command itself. it's that this job runs as root on a schedule. anyone who can write to that directory, even a low privilege user with basic access, can plant specially named files and get root to execute something on their behalf the next time the cron job fires.

how to actually check your own systems

don't stop at eyeballing one line. go through this properly:

crontab -l -u root
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/

for every job you find that touches tar, chown, chmod, rsync, or basically any command run against a wildcard, ask two questions. who can write to that directory. and does the command run as root or another privileged user. if the answer to both is "more people than i'd like," you have exposure.

also check permissions on the directory itself:

ls -ld /path/to/backup/folder

if that folder is group writable or world writable and a privileged cron job touches everything in it with a wildcard, that's your finding.

how to fix it

the fix is cheap and doesn't require rewriting your backup strategy. a few options, use whichever fits:

lock down the directory. make sure only root or the specific service account can write to the folder that gets archived. no shared write access, no "temp" folders where five people dump files.

stop using bare wildcards. instead of tar czf backup.tar.gz *, be explicit:

tar czf backup.tar.gz ./*

the ./ prefix stops filenames starting with a dash from being interpreted as flags, since tar sees them as paths, not options. it's a small change that closes the door.

use -- to end option parsing. most gnu tools respect this:

tar czf backup.tar.gz -- *

everything after -- is treated as a filename, period, no exceptions.

audit regularly. cron jobs are one of those "set it up in 2019 and never look at it again" things. put a recurring reminder on your calendar to review every scheduled job running as root, not just the ones you remember writing.

the takeaway

this isn't some exotic zero day. it's an old, well known trick that still works because cron jobs are invisible until something breaks. run that crontab -l check on your own systems today, look at every job running as root, and fix the wildcards before someone else finds them for you. boring maintenance is still the best defense there is.