It may be worth mentioning that a recent expose' on bad CGI scripts by Rain Forest
Puppy in Prack issue #55  revealed that some system calls take backslashes and use
them to escape dots, so its useful to get into the habit of also checking for
optionally backslashed periods in a row instead of just two periods in a row
alone.

http://www.phrack.com/search.phtml?view&article=p55-7

I've recently been involved with writing a standard set of modules to perform
untainting type of operations such as this. And, of course, generically untainting
paths is no easy matter at all as pointed out previously since paths by their
definition can contain shell metacharacters. :(

Of course, in the case of the handler, you are probably OK since the plain open
call probably won't do any shell interpolation.

"Randal L. Schwartz" wrote:

> >>>>> "Sean" == Sean Chittenden <[EMAIL PROTECTED]> writes:
>
> Sean>   Hey.  So I just went through and was auditing someone's code today
> Sean> (the joy of joys that it is) and these guys were pretty reliant on their
> Sean> access, authen, authz handlers for most everything related to their site
> Sean> (not too atypical, IMHO).  Everything was kosher EXCEPT they _never_
> Sean> tested for the '.' or '..' directories in their path.  For instance:
>
> "." as a directory name should never be a problem.  I'd like to see a
> case where you think it might.  ".." is, as you note, a problem.
>
> Sean>   # Match ./  and /.
> Sean>   if ($uri =~ m:\/\.|\.\/:o) { # Overly paranoid, but acceptable, regexp
> Sean>     return(HTTP_NOT_ACCEPTABLE);
> Sean>   }
>
> Naah, I'd go with something like this:
>
>   return HTTP_NOT_ACCEPTABLE if grep $_ eq "..", split /\//, $uri;
>
> Then "foo..bar" is OK, as is ".foo".  Of course, I reject ".ANYTHING"
> in my access handler, but that's up to you. :)
>
> Also, I noticed that "fancyindexing" uses "/foo/bar/bletch/..", so you
> have to permit that unless you want a lot of errors in your errlog
> when you turn fancyindexing on.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <[EMAIL PROTECTED]> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Reply via email to