full-disclosure - Bug with .php extension?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue Dec  6 19:22:18 2005
From: greed at pobox.com (Graham Reed)
Subject: Bug with .php extension?

Christopher Kunz writes: 

> Well, actually, I think this is some kind of "feature" and is associated with
> the behavior that is i.e. demonstrated on default installations of Apache (which
>  have several index.html index.html.de .en .jp etc.), only that this time not
> mod_negotiation, but mod_mime is responsible.

Not only is it a feature, it's documented: 

<http://httpd.apache.org/docs/2.0/mod/mod_mime.html> 

The docs note that the rightmost extension for a paricular category of meta 
data is used.  The exeption is languages and encodings, where they 
accumulate instead. 

Unknown extensions contribute nothing, and since they're unknown, it isn't 
known which category they aren't known for, so nothing happens with them. 

So, anything dealing with Apache-served files must not look only at the 
file's suffix, but all positions. 

To secure the user-upload area discussed earlier, you need to do one of: 

 - Sanitize to a known set of extensions and only allow known-valid groups of 
content, languate, and encoding extensions.  (So .tar.gz is fine, but 
.php.gz is probably bad.) 

 - Disable PHP for the upload area (is this possible?  I don't use PHP 
myself) 

 - Use ForceType to set a particular type.  You've still got to worry about 
extension-based (instead of type-based) handlers and things link that. 

 - Put up the AddTypes for PHP types only in known-php directories.   In this 
case, you would want your user upload area to be in a totally different 
place from your DocumentRoot so you don't get anything set on DocumentRoot 
leaking into the writable subdirectory.  (That's a good idea in general, of 
course; any server directory with a different security policy from 
DocumentRoot should be somewhere other than under DocumentRoot.)