{"vuid":"VU#439395","idnumber":"439395","name":"Apache web server performs case sensitive filtering on Mac OS X HFS+ case insensitive filesystem","keywords":["Apache web server","case sensitive","Mac OS X","Mac OS 10","HFS+","case insensitive filesystem"],"overview":"The Apache (1.3.14) web server's file access protection scheme can be bypassed for the Mac OS X HFS+ filesystem.","clean_desc":"The Apache web server's file access protection scheme (i.e., file request \"filtering\") assumes that the filesystem being protected is case sensitve. For example, in a case sensitive file system, such as UFS (the UNIX file system), the file name \"ANY_file\" and \"any_FILE\" refer to different files. The Mac's HFS+ filesystem is case insensitve (e.g., the names \"ANY_file\", \"any_FILE\", and \"any_file\" all refer to the same file) . Under the Apache file access protection scheme you specify the directory (e.g., /ANY_directory) or filename (e.g., \"/ANY_directory/ANY_file\") to be protected, but only directories or pathnames matchings the exact case you specify will be protected. Under the Apache scheme, you specify whether to deny or allow access to a filesystem object (which can be a directory, filename, or URL). The specifications are called \"directives\", which include <Directory>, <Files> and <Location> directives. See http://httpd.apache.org/docs/mod/core.html#directory for further information on directives. When you use a directive to deny access to a file or directory using the Apache web server under Mac OS X HFS+, the directive will NOT deny access to any other upper and lover case variation on the filename or directory.","impact":"Can bypass Apache file access protection, allowing remote unprivileged users to read privileged files.","resolution":"Solution 1 - By default, Apache will allow access to any file mapped from a URL  You should change the default to deny all access, and then use directives to override and allow access for only those directories and files that you want to be readable. Use regular expressions with directives such as <FilesMatch> and <DirectoryMatch> to cover upper and lover case variations. Be sure to thoroughly test your directives to ensure that Apache is properly allowing or denying access. The follwing advice is from the Apache web site (http://httpd.apache.org/docs/mod/core.html#directory): Note that the default Apache access for <Directory /> is Allow from All. This means that Apache will serve any file mapped from an URL. It is recommended that you change this with a block such as <Directory /> Order Deny,Allow\n     Deny from All\n </Directory> and then override this for directories you want accessible. See the Security Tips (http://httpd.apache.org/docs/misc/security_tips.html) page for more details. Solution 2 - At least a partial fix (a shared object file \"mod_hfs_apple.so\") is available on the Apple web site as part of thr Web Sharing version 1.0 released on 7-23-2001 -- http://www.apple.com/downloads/macosx/apple/websharingupdate.html . This update fixes the problem when you specify protected directories (using the <Directory> and <Location> directives), but the fix may not work when you specify individual file names to be protected (using the <Files> directive. (See the 13-July-2001 message from Jacques Distler on the following web page: http://www.macintouch.com/mosxreaderreports43.html.) To overcome the case problem for individual filenames, you need to use the <FilesMatch> directive, and specify the filename using regular expressions that cover all upper and lower case variations. Even after applying this patch, it is recommended that you set the Apache default to deny all access, as described in solution 1 above. Solution 3 - Use the UFS (Unix File System) instead of HFS+. UFS is case sensitive, so everything works as expected. Even if you use UFS, we still recommended that you set the Apache default to deny all access, as described in solution 1 above.","workarounds":"","sysaffected":"","thanks":"This vulnerability was initially posted to the bugtraq mailing list (bugtraq ID 2852) by Stefan Arentz.","author":"This document was written by Howard Lipson.","public":["http://www.securityfocus.com/bid/2852","http://www.apple.com/downloads/macosx/apple/websharingupdate.html","http://www.macintouch.com/mosxreaderreports43","http://www.securityfocus.com/bid/3316","http://httpd.apache.org/docs/mod/core.html#directory","http://httpd.apache.org/docs/misc/security_tips.html"],"cveids":["CVE-2001-0766"],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2001-06-14T17:48:50Z","publicdate":"2001-06-10T00:00:00Z","datefirstpublished":"2001-09-28T20:33:52Z","dateupdated":"2003-06-02T19:06:13Z","revision":53,"vrda_d1_directreport":"","vrda_d1_population":"","vrda_d1_impact":"","cam_widelyknown":"15","cam_exploitation":"0","cam_internetinfrastructure":"0","cam_population":"4","cam_impact":"8","cam_easeofexploitation":"20","cam_attackeraccessrequired":"20","cam_scorecurrent":"3.6","cam_scorecurrentwidelyknown":"4.8","cam_scorecurrentwidelyknownexploited":"9.6","ipprotocol":"","cvss_accessvector":"","cvss_accesscomplexity":"","cvss_authentication":null,"cvss_confidentialityimpact":"","cvss_integrityimpact":"","cvss_availabilityimpact":"","cvss_exploitablity":null,"cvss_remediationlevel":"","cvss_reportconfidence":"","cvss_collateraldamagepotential":"","cvss_targetdistribution":"","cvss_securityrequirementscr":"","cvss_securityrequirementsir":"","cvss_securityrequirementsar":"","cvss_basescore":"","cvss_basevector":"","cvss_temporalscore":"","cvss_environmentalscore":"","cvss_environmentalvector":"","metric":3.6,"vulnote":null}