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-next>] [day] [month] [year] [list]

Date: Mon Dec  5 04:34:41 2005
From: iago at valhallalegends.com (Ron)
Subject: Bug with .php extension?

I'm not sure whether this is something that's well known, but I've never 
seen anything about it, and I nearly got burned by it, so I figured I'd 
post it here.

In Apache 1.3.33 (untested on any other version), if you have a file 
called file.php.bak, and you navigate to it in the browser, it will run 
on the server as a .php file.  This works with any extension that isn't 
known to the server (.rar, .bak, .test, .java, .cpp, .c, etc.)

This can impact upload scripts, if they don't rename.  I had a script 
that was only allowing a very limited number of file names, including 
.rar.  I realized that I could upload the file test.php.rar, as 
demonstrated here:
http://www.javaop.com/~iago/test.php.rar

(I assure you that that's a .php script, not just that text file).

Resolution: If any script does that, it should be changed such that it 
renames any files, perhaps to a SHA1() hash of the filename, or a 
timestamp, or anything like that.

This problem reminds me of a recent discussion about files like 
file.exe.txt in Windows.

In general, that's good advice anyways, you shouldn't allow any kind of 
user specific filenames.  But just in case somebody is making this 
mistake, be careful!   As I said, I nearly got burnt by this, luckly I 
noticed it before anybody malicious did.

Ron