httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allan Edwards" <...@raleigh.ibm.com>
Subject RE: cvs commit: apache-1.3 STATUS
Date Wed, 07 Jun 2000 23:46:39 GMT
> -----Original Message-----
> From: wrowe@locus.apache.org [mailto:wrowe@locus.apache.org]
> Sent: Saturday, June 03, 2000 10:48 PM
> To: apache-1.3-cvs@apache.org
> Subject: cvs commit: apache-1.3 STATUS
>
>
> wrowe       00/06/03 19:48:00
>
>   Modified:    .        STATUS
>   Log:
>     Add Mark Slemco's observations as a showstopper to
> permanently close
>     this potential security hole.
>

>   +    * Complete the security hole in stat() by testing for anything
>   +      other than conventional file-not-found,
> permission-denied errors
>   +      and rejecting the request then and there.  By rights, all of
>   +      these cases aught to be Not Found, not Permission Denied.

I'm not sure there's anything else to do here. On NT, the stat() in get_path_info is returning
an error for strlen=MAX_PATH, we
get errno=2 (GetLastError = PATH_NOT_FOUND). For strlen>MAX_PATH we get errno=2 (GetLastError
= FILENAME_EXCED_RANGE). The
problem is just that ap_is_os_filename_valid in directory_walk didn't do its job of catching
the length error. As a result, the
stat() failure made it look like the DirectoryIndex file had not been found. So we didn't
bail, but rather continued on to the
next handler, and mod_autoindex served up the directory listing.

In Apache 2.0 the stat() call is replaced by ap_stat(), and GetFileAttributesEx returns the
same GetLastError statuses as above.
It would be easy to add the strlen>=MAX_PATH check inside ap_stat to return ERROR_FILENAME_EXCED_LENGTH,
but I'm not sure it's
worth doing. However, if people feel sufficiently paranoid let me know.

Allan


Mime
View raw message