Re: More security problems in Apache on Mac OS X

["Paul Lieberman" <lieb () sou edu>]

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                                     lieb () sou edu
Systems Engineer                                 541-552-6962
Computing Services Center
Southern Oregon University
Ashland, OR


> Jacques Distler <distler () golem ph utexas edu> 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-----