Vulnerability Development mailing list archives

Re: Apache 2.x leaked descriptors


From: "David M. Wilson" <dw-securityfocus.com () botanicus net>
Date: Mon, 24 Feb 2003 00:46:56 +0000

On Sat, Feb 22, 2003 at 02:46:59PM -0800, jon schatz wrote:

you can do more than that. unless the web server uses suexec, all the 
cgi's run as the webserver user, who most likely has:

at least w to all log files for all vhosts (probably r+w)

Installations like this are few and far between, it is the equivilant of
chmod 777 /etc/passwd. Apache opens log files while still root, so write
permission granted to the lower-permission Apache user should rarely
happen in a properly administered environment.


at least r on all webhosting directories

In a properly administered environment (where directory indexes are not
enabled) you will at best have execute premissions, leaving you the
option of brute-forcing the names of files in webroots.

This is true since if indexing is disabled (mod_autoindex is disabled or
not compiled in, and no DirectoryIndex entry which points to an indexing
script is specified), Apache never attempts to read a directory, it only
needs to stat() and open() inside it to serve GET/HEAD/POST requests.


at least r+x on all cgi-bin directories

Ideal permissions on CGI directories do not differ to the permissions on
other content directories. I think you may be confused as to what
execute permission actually means:

Execute permission on a directory does not mean that its content is
executable, but that a process may chdir() into that directory and
access files by name inside that directory. Read permission on a
directory means a process may list its contents via readdir(), or
getdents(), etc.


David.


Current thread: