Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.Hawaii.Edu!ames!enews.sgi.com!news.sgi.com!howland.erols.net!newsxfer3.itd.umich.edu!bloom-beacon.mit.edu!pad-thai.cam.ov.com!not-for-mail
From: jik@cam.ov.com (Jonathan I. Kamens)
Newsgroups: comp.security.unix,comp.unix.bsd.freebsd.misc
Subject: Re: Why is cleaning /tmp with find a security problem?
Date: 20 Mar 1997 14:23:18 GMT
Organization: OpenVision Technologies, Inc.
Lines: 50
Message-ID: <5grh8m$fb0$1@pad-thai.cam.ov.com>
References: <5gq5q6$cst@mozo.cc.purdue.edu>
NNTP-Posting-Host: gza-client1.cam.ov.com
X-newsreader: xrn 8.03-beta-24
Xref: euryale.cc.adfa.oz.au comp.security.unix:32867 comp.unix.bsd.freebsd.misc:37553
In article <5gq5q6$cst@mozo.cc.purdue.edu>, ajk@schwinger.physics.purdue.edu (Andrew J. Korty) writes:
|> From the stock /etc/daily distributed with FreeBSD:
|>
|> # This is a security hole, never use 'find' on a public directory
|> # with -exec rm -f as root. This can be exploited to delete any file
|> # on the system.
|> #
|> #find / \( ! -fstype local -o -fstype rdonly \) -a -prune -o \
|> # \( -name '[#,]*' -o -name '.#*' -o -name a.out -o -name '*.core' \
|> # -o -name '*.CKP' -o -name '.emacs_[0-9]*' \) \
|> # -a -atime +3 -exec rm -f -- {} \;
|>
|> Why? The first thing that comes to mind is that it has to do with
|> symbolic links, but "find" won't follow them unless you tell it to. Am
|> I missing something obvious?
I suspect the comment is confused, and its author was thinking about
a similar security problem which doesn't actually occur here.
Cleanup commands of this sort in crontabs used to be in the form "find
... -print | xargs rm -f". That *is* a security hole, because an
attacker can create a filename with a newline in it and cause xargs to
treat everything after the newline as a separate argument to rm. For
example:
> cd /tmp
> touch 'foo\^Jbar'
> find . -name 'foo*' -print
./foo
bar
> find . -name 'foo*' -print | xargs ls
./foo not found
bar not found
> find . -name 'foo*' -ok rm {} \;
< rm ... ./foo
bar >? y
>
The ramifications of this are left as an exercise to the reader.
The solution to this security hole is either (a) use a version of find
that supports "-print0" and a version of xargs that supports "-0", so
that newline is no longer the separator, since it's impossible for a
user to create a filename with a null in it, or (b) use -exec as shown
in the command above instead of -print piped into xargs. Since the
command commented out above uses -exec, I don't think it's a security
problem.
--
Jonathan Kamens | OpenVision Technologies, Inc. | jik@cam.ov.com