Find+rm security hole in debian?
I received the following concerning a security problem with clean-up
cron jobs that use find+rm.
Any comments from gurus?
-Billy
- ---------- Forwarded message ----------
Date: Tue, 21 May 1996 13:10:36 -0400 (EDT)
From: Zygo Blaxell <zblaxell@myrus.com>
To: linux-security@tarsier.cv.nrao.edu, best-of-security@suburbia.net
Subject: [linux-security] Things NOT to put in root's crontab
Sigh. Here are several things I've just removed from /etc/crontab on
every RedHat Linux system I can get my hands on. They contain security
holes related to the use of 'find' and 'rm' to expire old files in /tmp
and other places.
It seems that awareness of this type of security problem is rather low,
so I'll explain the class of problem and how to fix it.
>From Redhat's /etc/crontab file:
># Remove /var/tmp files not accessed in 10 days
>43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null
>
># Remove /tmp files not accessed in 10 days
># I commented out this line because I tend to "store" stuff in /tmp
># 41 02 * * * root find /tmp/* -atime +10 -exec rm -f {} \; 2> /dev/null
>
># Remove formatted man pages not accessed in 10 days
>39 02 * * * root find /var/catman/cat?/* -atime +10 -exec rm -f {} \; 2> /dev/null
>
># Remove and TeX fonts not used in 10 days
>35 02 * * * root find /var/lib/texmf/* -type f -atime +10 -exec rm -f {} \; 2> /dev/null
Folks, do NOT use 'find' on a public directory with '-exec rm -f' as root.
Period. Ever. Delete it from your crontab *now* and finish reading the
rest of this message later.
* PROBLEM DISCUSSION AND EXPLOITATION
The immediate security problem is that 'rm' doesn't check that
components of the directory name are not symlinks. This means that you
can delete any file on the system; indeed, with a little work you can
delete *every* file on the system, provided that you can determine the
file names (though you might be limited to deleting files more than ten
days old).
First, create the directories and file:
/tmp/hacker-fest/some/arbitrary/set/of/path/names/etc/passwd
where all but the last component is a directory. Be ready to
replace 'etc' with a symlink to '/etc', so that:
/tmp/hacker-fest/some/arbitrary/set/of/path/names/etc -> /etc
i.e. the path components of the file name will point to a file named
'passwd' in a different directory.
If the replacement operation occurs between when 'find' sets {} to
"/tmp/hacker...etc/passwd" and when 'rm' calls unlink on
"/tmp/hacker...etc/passwd", then rm will in fact delete '/etc/passwd',
and not a file in /tmp. Deleting other files is left as an exercise.
The race condition is really easy to win. Create a directory with 400
path components, like this:
...
[clip]
...
* OTHER PROBLEMS WITH THIS CRONTAB
A user can set the atime of any file they own to an arbitrary value, and
that programs like zip, tar, and cpio will do this for you
automatically; this makes 'atime' an almost useless indicator of when a
file was last used ('mtime' has the same problem). Either the file will
be deleted too early, because it was extracted from an archive using a
program that preserves timestamps, or users can set the atime to well
into the future and use /tmp space indefinitely. The later of ctime (to
detect writes) and atime (to detect reads; must check that atime is not
in the future) is a good indicator of when a file was last used.
...
[clip]
...
* SAFE LRU GARBAGE COLLECTION
Our LRU /tmp garbage collector daemon is available at
<URL:http://www.ultratech.net/~zblaxell/admin_utils/filereaper.txt>. It
is implemented in perl5. It depends on a Linux-specific 'statfs()'
system call to monitor available free space, so non-Linux people will
need to do a port (send me patches and I'll incorporate them).
Our garbage collector:
handles the above security problems correctly,
handles pathnames more than 1024 characters,
uses smarter last-access estimates than just atime or ctime,
can support "permanent" subdirectories,
handles files, symlinks, directories, devices, mount points correctly,
can support minimum age of files (e.g. no files < 1 day old),
deletes oldest files first,
deletes files only when disk space is low,
and responds in less than ten seconds to low disk space conditions.
Our garbage collector works on any directory where files can gracefully
disappear at arbitrary times, such as /var/catman, /tmp, /var/tmp,
TeX font directories, and our HTTP proxy cache. One directory where
the garbage collector doesn't work very well is /var/spool/news; we
had to hack things up a bit to fix the article databases when article
files disappear.
- --
Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science
Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate
Programming Contest Finals, 1994. Administer Linux nets for food, clothing,
and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong
- --
Billy C.-M. Chow billy.chow@eng.ox.ac.uk Debian Linux
------- end -------
Reply to: