NetBSD Problem Report #2451

From gnats  Tue May 21 14:32:17 1996
Received: from ns.southern.net by pain.lcs.mit.edu (8.7.4/8.6.12) with ESMTP id OAA24217 for <gnats-bugs@gnats.netbsd.org>; Tue, 21 May 1996 14:25:42 -0400 (EDT)
Message-Id: <199605211825.TAA01373@orwell.southern.net>
Date: Tue, 21 May 1996 19:25:28 +0100 (BST)
From: david@mono.org
Reply-To: david@mono.org
To: gnats-bugs@gnats.netbsd.org, misc@openbsd.org
Subject: Security hole in /etc/daily  (find + rm)
X-Send-Pr-Version: 3.95

>Number:         2451
>Category:       security
>Synopsis:       Security hole in /etc/daily  (find + rm)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 21 14:35:09 +0000 1996
>Closed-Date:    Wed Jan 06 03:07:49 +0000 1999
>Last-Modified:  Wed Jan 06 03:28:10 +0000 1999
>Originator:     David Brownlee
>Release:        1.1B
>Organization:
	Monochrome (http://www.mono.org)
>Environment:

System: NetBSD orwell.southern.net 1.1B NetBSD 1.1B (_SUN4C_) #0: Tue Apr 2 08:44:20 PST 1996 david@orwell.southern.net:/usr/src/sys/arch/sparc/compile/_SUN4C_ sparc


>Description:
	The combination of find & rm used in /etc/daily leaves an opportunity
	for a hacker to delete any files on the system.
	(It does under linux, and I'm assuming we're equally open here).

>How-To-Repeat:
	Forwarded message from zblaxell@myrus.com detailing the problem

From zblaxell@myrus.com Tue May 21 19:24:13 1996
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: BoS: Things NOT to put in root's crontab
Resent-Date: Wed, 22 May 1996 03:11:15 +1000
Resent-From: best-of-security@suburbia.net

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.

>Fix:
	Unknown...
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: lukem 
State-Changed-When: Sun Jun 22 22:02:20 PDT 1997 
State-Changed-Why:  
These find's are commented out in -current's /etc/daily script. 
Is this sufficient? 

From: David Brownlee <abs@anim.dreamworks.com>
To: gnats-bugs@gnats.netbsd.org
Cc:  Subject: security/2451: Security hole in /etc/daily
Date: Sat, 15 Aug 1998 20:34:57 -0700 (PDT)

 	If a comment is added to /etc/daily indicating how much of a
 	security hole the code would be if uncommented, the case can
 	probably be closed.

 		David/absolute

State-Changed-From-To: feedback->closed 
State-Changed-By: abs 
State-Changed-When: Tue Jan 5 19:07:49 PST 1999 
State-Changed-Why:  
Add comment to daily. 
>Unformatted:
 >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:

 	/tmp/hacker-fest/a/a/a/a/a/a/a.../a/a/a/etc/passwd	(1)

 Then arrange for each of the 'a' components to be a symlink to a
 directory somewhere near the bottom of a similar tree.  For example,

 	/tmp/hacker-fest/a

 could be a symlink to

 	/tmp/hacker-fest/b/b/b/b/b/b/b/b/b/.../b/b/b/b/b/b/a

 which could be a symlink to

 	/tmp/hacker-fest/c/c/c/c/c/c/.../c/c/c/c/c/c/c

 and so on.  In fact, *each* path component can be a symlink up to about
 8 levels or so.  Any operation such as stat(), open(), lstat(), etc.
 on one of these pathnames will cause the kernel to follow each and every
 symlink.  The difference between lstat() and stat() in this case is that
 lstat() will not follow the *last* symlink.

 This will make lstat() and friends *extremely* slow, on the order of
 several *minutes* per lstat() operation, because each lstat() is now
 reading in several thousand inodes and disk blocks.  If you fill each
 directory with several hundred entries, then create the entry you want,
 then delete the others, you force the kernel to waste its time reading
 kilobytes of empty directory blocks--in fact, you can make one stat() or
 unlink() operation read almost the entire disk in an order designed to
 maximize disk head motion if you know what you're doing.  If you have an
 NFS, CDROM, or floppy-disk filesystem handy, you can get *weeks* per
 lstat().  

 Of course, 'find' will normally see the first symlink and stop.  To
 prevent this, you rename the original directory (at (1) above) and
 create another directory with the same name and about 5000 empty files,
 some of which have the same name as files you want to delete.  Note that
 these 5000 empty files can all be hard links to the same file, to save
 precious inodes for more of those symlinks.

 'find' will spend considerable time iterating through these 5000 files.
 When it does (you'll be able to tell because the atime of the directory
 changes as find reads it), put the directory with the millions of
 symlinks at (1) back with a couple of rename operations.  Some versions
 of 'find' will not be adversely impacted by this, but 'rm' definitely
 will.

 It is usually sufficient to simply create the 400-component-long
 directory, put 5000 files in it, wait for the atime of the directory to
 change, then do the rename so that 'rm' follows a symlink.  I used this
 technique to remove /etc/crontab as a test case.  

 If you have:

 	/tmp/hacker-fest/a/a/a/a/a/.../a/etc/passwd (and 5000+ other files)
 	/tmp/hacker-fest/a/a/a/a/a/.../a/usr

 where 'usr' is a symlink to '/usr', you can get some implementations of
 find to start recursing through /usr as well.

 * 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.

 Miscellaneous bugs:  the use of '*' means that files in a directory
 named '.foo' will never be cleaned (and you can prevent 'find' from
 working at all by putting more than 1020 files in /tmp).  There are
 subdirectories of /var/catman that aren't properly handled by the 'find'
 command given (local and X11).  You can't delete a directory with
 'rm -f'.

 In other words, not only is RedHat's /etc/crontab a major security hole,
 it doesn't actually work properly, either.  :(

 * FIXES

 The easiest way to fix this is to get rid of the find/rm stuff
 completely.  If you need a garbage collector, try our LRU garbage
 collection daemon at the URL given below.

 Adding a system call that sets a flag that prevents a process from being
 able to ever follow a symlink would be non-portable, but efficient and
 effective.

 The next easiest way to fix this is to replace 'rm' with a program that
 does not follow symlinks.  It must check that each filename component in
 turn by doing an lstat() of the directory, chdir() into the directory,
 and further lstat()s to check that the device/inode number of '.' is
 the same as the directory's device/inode number before chdir().  The
 parameter of the 'unlink' or 'rmdir' system call must not contain a
 slash; if it does, then the directory name before the slash can be
 replaced by a symlink to a different directory between verification of
 path components and the actual unlink() call.

 Another way to fix this is with a smarter version of find.  A smart
 find does the chdir() and lstat() checks to make sure that it never
 crosses a symlink, and calls the program in 'exec' using a filename
 with no directory components, relative to the current directory.  
 Thus, to delete:

 	/tmp/hacker-fest/a/a/a/a/a/.../etc/passwd

 find first carefully (checking for attempts to exploit race conditions
 before and *after* each chdir()) chdir()s into

 	/tmp/hacker-fest/a/a/a/a/a/.../etc

 and will fail if any of the components is a symlink, plugging the hole
 described above.  After verifying that the '.../etc' is really a
 subdirectory of /tmp, and not some random point on the filesystem, find
 exec's the command:

 	rm -f ./passwd

 which is secure as long as '.' isn't in your PATH.  Note the leading
 './' to prevent rm from interpreting the filename as a parameter.

 Note: this is in *addition* to the checks that find already makes to
 determine whether a file is a symlink *before* chdir()ing into it.  It must
 make sure that components of the path that have *already* been tested
 are not replaced with symlinks or renamed directories *after* find has
 started processing subdirectories of them.

 Note that the 'smart' find without the post-chdir symlink tests won't
 work.  While smart-find is processing:

 	/tmp/hacker-fest/a/a/a/a/*

 you can rename

 	/tmp/hacker-fest/a/a/a/a

 to

 	/tmp/hacker-fest/a/a/b	(note: one less pathname component)

 and eventually smart-find will 'cd ..', but since the current directory
 of find has moved, '..' will move as well, and eventually smart-find
 will be one level too high and can start descending into other
 subdirectories of '/'.  To help this along you may need to create:

 	/tmp/hacker-fest/usr
 	/tmp/hacker-fest/var
 	etc.

 * 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

Home	PR Database Search