Subject: Re: CVS commit: src/usr.bin/find
To: None <tech-userlevel@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-userlevel
Date: 02/08/2007 23:36:17
> We could safely use "find *" to list files recursively excluding
> dot-files in the current directory.
> (This may not always work correctly, but it is safe, anyway.)

Not necessarily - consider a file named "-exec".  (Synthesizing the
rest of a useful command is likely to be tricky, but I'm by no means
certain it can't be done.)

Doing pretty much anything with * in directories potentially
constructed by malicious users is...risky.  To put it mildly.

> If the function is implemented as, "-exec find-builtin-rm '{}' ';'",
> it should be much safer.
> 
> 	% touch ./-exec find-builtin-rm '{}' \;
> 	% echo *
> 	-exec ; find-builtin-rm {}

BUT....

mkdir ,dir
touch ,dir/file ./-exec sh
cp ~/nasty-script very-evil-script

Now,

find * -exec find-builtin-rm '{}' \;

-> find ,dir -exec sh very-evil-script -exec find-builtin-rm '{}' \;
   -> oops!

This took me about five minutes to construct.  What will the attackers
come up with when they have person-years available to think about
possibilities?  Would *you* bet *your* system on the result?
Especially when a trivial fix - "find ./* ..." - is available?

Which is all to say, I see no point in worrying about what "find * ..."
can do in a directory constructed by a putative attacker.  It's trivial
to avoid and extremely hard to fix completely.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B