>> Jonathan wrote:
>> I don't think the shell is called to
>> resolve the "/home/users/me/web/$in
>> {'NAME'}.ext" bit, and therefore
>> you cannot run commands with it.
>
> Randal wrote:
> It would be if $in{NAME} contained "|\0".
> NULL characters terminate the string, and
> if | appears just before that, bingo, it's
> a shell command, not a file open. Trivial
> to get:
> /cgi-bin/yourscript?NAME=%7C%00
>
> All that's needed now is to make that
> "\n/evil/command|\0" instead. I'll leave
> that up to the guy that's about to visit
> your site. :)
Ah, now there's one I forgot about. AFAIK Perl handles
null characters perfectly (8 bit clean :), but many
programs based on C aren't (not properly checked). It's
fine UNTIL perl uses it externally... might be good to
try, just in case Perl's magic does something about it.
Did anyone mention Taint mode? It's really not that hard.
Going back to the original problem, I suggest you don't use
the filesystem at all. A database might be safer in this
instance, and would be my preferred solution. Creating
files based on unchecked (anonymous) user input just seems
stupid to me. Alternatively setup the script in a chroot
enviroment, which is a little safer.
However, if it makes coding easier, and you can afford a
few hacks once and a while why not try tripwire - at least
you'll know when things have been changed. (Bad advice...
fix the real problem before looking at security tools).
Jonathan Paton
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music
Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
