On 12 Feb 2001 [EMAIL PROTECTED] wrote:
> 1.160 +15 -0 apache-1.3/src/main/http_request.c
>
> Index: http_request.c
> ===================================================================
> RCS file: /home/cvs/apache-1.3/src/main/http_request.c,v
> retrieving revision 1.159
> retrieving revision 1.160
> diff -u -u -r1.159 -r1.160
> --- http_request.c 2001/01/15 17:05:02 1.159
> +++ http_request.c 2001/02/12 10:18:04 1.160
> @@ -907,6 +907,21 @@
> ap_parse_uri(rnew, rnew->uri); /* fill in parsed_uri values */
> if (stat(rnew->filename, &rnew->finfo) < 0) {
> rnew->finfo.st_mode = 0;
> +#ifdef ENAMETOOLONG
> + /* Special case for filenames which exceed the maximum limit
> + * imposed by the operating system (~1024). These should
> + * NOT be treated like "file not found", because there is
> + * a difference between "the file is not there" and
> + * "the file exists, but you tried to access it using a
> + * path which exceeds the path length limit".
> + * The idea here is to handle DoS attacks with long
> + * runs of //////'s in a graceful and secure manner.
> + */
> + if (errno == ENAMETOOLONG) {
> + rnew->status = HTTP_FORBIDDEN;
> + return rnew;
> + }
> +#endif
> }
>
> if ((res = check_safe_file(rnew))) {
>
Shouldn't this use the same sort of logic that is used in get_path_info
(normally called by directory_walk, except that the short circuiting in
this case skips the security check that was already in directory_walk
for this sort of stuff... does it skip anything else that matters
too?)? Since it is doing the same thing, just taking a shortcut to it.
ie. only known errnos such as ENOENT result in a NOT_FOUND, everything
else results in a FORBIDDEN? Otherwise, you can still be revealing stuff
if you get an EIO due to some kooky (perhaps filesystem-specific) error
condition, etc. that may be exploitable.
