Guide to PHP SecurityQuicksearchCalendar
|
Monday, August 30. 2010Beware of the default Apache 2 config for PHP
About a week ago, I was doing some upgrades on my development machine and came across a rather nasty issue when it comes to how .php(s) files are associated with PHP in Apache. It seems that a number of distros including Gentoo (which is what I was using) are using the following configuration directive to make the PHP module parse PHP files:
The non-obvious problem with the above is that it will allow not only "file.php" to be treated as PHP scripts, but also "file.php.txt", which means that any file containing ".php" in its name, no matter where in the filename, would be treated as a PHP script. This of course creates a rather nasty security hole, since many upload file validation tools, only check the final extension. Consequently allowing the user to by-pass the validation, by simply prefixing another "harmless" extension like .txt, .pdf, etc... to the filename, but still get the code to execute. To mitigate this problem you should instead use the following configuration, that would only pick-up of files ending with a .php extension. The difference between the two configurations being that the original uses AddHandler (bad) and the latter uses AddType (good). Comments
Display comments as
(Linear | Threaded)
This sounds more like an Apache bug. Using AddType instead of AddHandler has other side effects; namely, it screws up content negotiation.
Actually AddHandler works exactly as described, even apache documentation mentions it should be used very carefully, since it will pick up on things like foo.bar.php.txt.
I have yet to see the "content negotiation" issues you've mentioned, do you have any specific references?
I mean let's say you have named test.php. You use MultiViews and URLs without extensions, relying on content negotiation to find the most appropriate file. Let's say a UA makes a request like this:
GET /test HTTP/1.1 Host: whatever Accept: text/html With AddHandler and the type of .php set to text/html, this works fine. As soon as you replace AddHandler with AddType, you get this: HTTP/1.1 406 Not Acceptable Date: Tue, 31 Aug 2010 03:20:07 GMT Alternates: {"test.php" 1 {type application/x-httpd-php} {length 26}} Vary: negotiate This is because the content-type of .php files is not actually "application/x-httpd-php"; this is just a hack you use to force them to be interpreted as php scripts. There are actually UAs (I think Google Bot is on them) that send requests with an Accept header and without accepting */*. You are right, in that this is documented behavior, but it seems to be that you should stick to AddHandler and use instead something like (add <): FilesMatch "\.php."> RemoveHandler .php /FilesMatch>
This guy things you are wrong, go figure:
http://www.devside.net/articles/php
Well, it is not about wrong or right, If you want a.php.txt to be treated as a PHP script then, by all means use AddHandler. However if you only want files ending with .php to be parsed as PHP scripts you should use AddType.
See:
- http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addhandler - http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext - http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addtype Please read the documentation before making recommendations to other people. There's also 2 Gentoo bugs related to this (and similar) issues: - http://bugs.gentoo.org/show_bug.cgi?id=162478 - http://bugs.gentoo.org/show_bug.cgi?id=279099
This is not entirely correct, it depends on the bogus extension. If you append .txt to a PHP file, .txt get's precedence and the .PHP file is not executed. Only once the extension is unknown (say for example: file.php.fubar) then it get's parsed by the PHP engine.
I don't know exactly how it works with other known extensions, but I've written a blog about this topic a while back: http://blog.dynom.nl/archives/Be-careful-with-double-extensions_20081024_25.html
Actually with .txt the PHP code gets executed, one of the reasons I found the problem out since the test server had a script.php.txt file. When it was requested, instead of loading up text content, it showed the output of the PHP script instead.
Interesting behavior, I've tried it with several extension back then and it only worked on bogus file extensions. Not "known" file extensions.
Perhaps I used a different configuration and different apache version, it's still an interesting and potentially dangerous difference though.
Ubuntu (at least the current 10.04 LTS) uses a variant which in my opinion is a better solution than switching from AddHandler to AddType. FilesMatch check with a regular expression, what the truly last ending of the file is, and uses SetHandler accordingly.
... SetHandler application/x-httpd-php ...
Sorry, looks like the filter on this blog doesn't like Apache directives with brackets that look like HTML tags
It is FilesMatch "\.ph(p3?|tml)$"> SetHandler application/x-httpd-php /FilesMatch>
Thank you for this blog post Ilia. I was trying desperately to find out what was going on after the last upgrade.
The only message that I get (still unfortunately) is: Sep 6 01:27:34 machine kernel: [197892.053255] apache2[6193]: segfault at 69 ip 00007fa76c277294 sp 00007fff62820730 error 4 in libphp5.so[7fa76c1b6000+3b8000] That effectively is what is logged when I try to start apache. I tried the AddType approach on 70_mod_php5.conf file but the same error appeared again. Did you see something similar in your installation?
No, I am not seeing any crash messages from PHP.
thanks for your insightful tips, I was recently given an assignment to administer a LAMP server for my university dept. I'm not a natural-born administrator, rather an application developer, your tips really helped me in securing the server.
|
CategoriesSyndicate This BlogBlog Administration |
|||||||||||||||||||||||||||||||||||||||||||||||||










Comments