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