httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: 1.2b1 status
Date Thu, 28 Nov 1996 03:47:07 GMT
On Wed, 27 Nov 1996, Rob Hartill wrote:

> 	Security hole: [Brian] - Directory contents can be displayed
> 	when a index.html file is supposed to be 'protecting' the directory
> 	from view, this is due to a problem with negotiation/Multiviews/mod_dir
> 	when the client doesn't accept text/html.
> 	(Brian says this is a 1.2 showstopper (he didn't say 1.2b1)

I think it's a 1.2b1 showstopper. At any rate, I've enclosed a
fix. The problem is that mod_dir considers a 200 response from a
sub-request a sign of success (which may be a bad idea anyhow - I'm
not sure what happens if the client asks for a range), and if it gets
one, it passes that handler the index. If it doesn't get a 200, it
assumes that that file doesn't exist, and moves on to the next entry
in the DirectoryIndex list. If it doesn't find any, and indexing is
on, it creates a listing.

Brian is, I believe, using a DirectoryIndex of "index", or
somesuch. When mod_negotiation looks for an index file that matches an
Accept header of "image/gif" (to use Brian's example), it doesn't find
one. However, it does find a resource there, so it returns
406. mod_dir looks at this, sees that it's not a 200, so happily sends
along a directory listing.

This patch keeps track of whether any of the responses were
non-(200|404). If any were, it returns the last error code, instead of
creating a directory index. It doesn't do it right away, because one
of the others might match (e.g. if I had "DirectoryIndex index
welcome", I would want to serve a welcome.html file, even though the
index search returns a 406 because I didn't have a variant that

Now, the current behavior *could* be used as a feature. For example,
if I wanted members of a certain domain to view directories, but
everyone else to get specific index files, I could make the index
files forbidden to that specific domain (deny them access) - this
would cause mod_dir currently to serve directory listings.

Though I doubt anyone is "using" this feature. Anyhow, here's a patch:

Index: mod_dir.c
RCS file: /export/home/cvs/apache/src/mod_dir.c,v
retrieving revision 1.15
diff -c -r1.15 mod_dir.c
*** mod_dir.c	1996/11/03 20:48:33	1.15
--- mod_dir.c	1996/11/28 03:45:25
*** 768,773 ****
--- 768,774 ----
        (dir_config_rec *)get_module_config (r->per_dir_config, &dir_module);
      const char *names_ptr = d->index_names ? d->index_names : DEFAULT_INDEX;
      int allow_opts = allow_options (r);
+     int error_notfound = 0;
      if (r->uri[0] == '\0' || r->uri[strlen(r->uri)-1] != '/') {
  	char* ifile;
*** 808,815 ****
--- 809,831 ----
  	    return OK;
+ 	/* If the request returned something other than 404 (or 200),
+ 	 * it means the module encountered some sort of problem. To be
+ 	 * secure, we should return the error, rather than create
+ 	 * along a (possibly unsafe) directory index.
+ 	 *
+ 	 * So we store the error, and if none of the listed files
+ 	 * exist, we return the last error response we got, instead
+ 	 * of a directory listing.
+ 	 */
+ 	if (rr->status && rr->status != 404 && rr->status != 200)
+ 	    error_notfound = rr->status;
          destroy_sub_req (rr);
+     if (error_notfound)
+ 	return error_notfound;
      if (r->method_number != M_GET) return NOT_IMPLEMENTED;

Alexei Kosut <>      The Apache HTTP Server

View raw message