Re: More security problems in Apache on Mac OS X

From: Paul Lieberman (liebat_private)
Date: Tue Sep 11 2001 - 15:37:08 PDT

  • Next message: arkat_private: "Re: CERT Advisory CA-2001-25"

    After confirming this was true I also determined that the default block for .htxxxx files would fail if you typed them in uppercase in the url i.e http://some.macosx.server/.HTACCESS.
    After considering the filter shown below I thought why not just block all hidden files and so did the following..
    
    <FilesMatch "^\.">
        Order allow,deny
       Deny from all
    </FilesMatch>
    
    This matches any file that starts with a period and seems to do the trick. I can't think of an instance where you'd want a hidden file to display on the web. Am I missing something?
    
    --
    Paul Lieberman                                     liebat_private
    Systems Engineer                                 541-552-6962
    Computing Services Center
    Southern Oregon University
    Ashland, OR
    
    
    > Jacques Distler <distlerat_private> 09/10/01 07:02AM >>>
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    > 
    > [Originally posted to <http://www.macintouch.com/mosxreaderreports46.html>]
    >
    > We've already seen the security problems (or potential problems) in Apache
    > on MacOSX associated to the case-insensitivity of HFS+. By exploiting the
    > case-insensitivity of HFS+, an attacker can evade Apache's access controls.
    >
    > Using mod_hfs (which takes care of case-insensitivity in directory names)
    > and using <FilesMatch> (with well-chosen regular expressions) instead of
    > <Files> directives (to take care of case-insensitivity in filenames), we can
    > "cure" the case-insensitivity problem and restore Apache's access controls.
    >
    > But there's another gotcha lurking.
    > 
    > You typically don't want people to be able to obtain a list of files in your
    > web directory. To allow them to obtain such a list, you explicitly have to
    >
    > 1) NOT have an index.html file in the directory
    > 2) include an Options Indexes directive among the access controls for that
    > directory
    >
    > Or you could just run MacOSX.
    >
    > The Finder creates an invisible file, ".DS_Store" in each directory which
    > contains (among other binary gobledygook) a list of files in the directory.
    >
    > So, if you have EVER viewed a web directory in the Finder, an attacker can
    > just retrieve
    >
    >  http://your.mac.com/some_directory/.dS_store 
    >
    > to learn what files are in that directory.
    >
    > The solution is, again, to use a <FilesMatch> directive in httpd.conf to
    > forbid retrieval of this file:
    >
    > # The Finder creates an invisible .DS_Store file in each directory.
    > # For 'no-index' access controls to be effective, we had better forbid
    > # retrieval of that file as well. Note that we have to protect
    > # against the same case-insensitivity bug as above.
    > #
    > <FilesMatch "^\.[Dd][Ss]_[Ss]">
    > Order allow,deny
    > Deny from all
    > </FilesMatch>
    >
    > Note the regular expression to take care of case-insensitivity :-). And, of
    > course, you need to
    > 
    > sudo apachectl restart
    >
    > when you're done.
    > 
    > Of course, the real question is: why was this file created world-readable
    > in the first place?
    >
    > But then, Apple has taken a REALLY lax attitude about file permissions
    > throughout all of MacOSX.
    >
    > More on the security implications of that some other time . . .
    >
    > Jacques Distler
    >
    > -----BEGIN PGP SIGNATURE-----
    > Version: GnuPG v1.0.6 (Darwin)
    > Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc 
    >
    > iD8DBQE7nMfSnyqPIXpYcjcRAlOvAJ9AVuC9L3AAdUfokFBrSlN113JfbgCeKoep
    > uORBZBGqMIR6VW3PVFO39P4=
    > =IG6Q
    > -----END PGP SIGNATURE-----
    



    This archive was generated by hypermail 2b30 : Tue Sep 11 2001 - 16:49:35 PDT