Oh, and one caution on the logging that was added here: isn't the logging
going to be a potential DoS in itself almost?
Since it will happen for each subrequest. So if you have 30 variants,
couldn't you end up with 30 log messages for every hit that the client
makes? One definition of a DoS attack is something that lets an attacker
easily use a lot of resources on the server, and this seems to qualify.
I would also suggest different wording... saying what was detected, and
what was done about it in more specific terms instead of just a generic
message that doesn't actually say what is going on.
And what does a DoS attack have to do with this fix anyway?
On Mon, 19 Feb 2001, Marc Slemko wrote:
> 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.
>
