Re: Apache 2.x leaked descriptors

From: David M. Wilson (dw-securityfocus.comat_private)
Date: Sun Feb 23 2003 - 16:46:56 PST

  • Next message: Seth Knox: "Re: Bypassing Personal Firewalls"

    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.
    



    This archive was generated by hypermail 2b30 : Mon Feb 24 2003 - 13:23:20 PST