a recent post on bugtraq hilighted an issue with how upstream has configured apache to invoke php, namely using addhandler, which has the behavior of matching the extension anywhere in the file. this means that foo.php.jpg will be run as php. where this becomes an issue is web apps that allow uploads into the webspace for images, pdfs, etc. if the app assumes that anything.jpg is safe, this addhandler feature will surprise it.
a fix is to replace two lines in /etc/httpd/conf.d/php.conf:
AddHandler php5-script .php AddType text/html .php
with:
<FilesMatch .php$> SetHandler php5-script ForceType text/html </FilesMatch>
i have reported this upstream. hopefully they will see it as a problem and address it.
a recent post on bugtraq hilighted an issue with how upstream has configured apache to invoke php, namely using addhandler, which has the behavior of matching the extension anywhere in the file. this means that foo.php.jpg will be run as php. where this becomes an issue is web apps that allow uploads into the webspace for images, pdfs, etc. if the app assumes that anything.jpg is safe, this addhandler feature will surprise it.
Hi Joe,
Are you sure this is limited to just CentOS? I've seen that config used before on other distro's apache configs.
From the Apache 2.x Docs:
--- Care should be taken when a file with multiple extensions gets associated with both a MIME-type and a handler. This will usually result in the request being by the module associated with the handler. For example, if the .imap extension is mapped to the handler imap-file (from mod_imap) and the .html extension is mapped to the MIME-type text/html, then the file world.imap.html will be associated with both the imap-file handler and text/html MIME-type. When it is processed, the imap-file handler will be used, and so it will be treated as a mod_imap imagemap file. ---
So if example.php.gif is read by apache, the AddHandler for php5-script (mod_php) will take precedence over the mime-type handler for .gif (image/gif) and the file will be treated as a php script.
From that it almost sounds like it's not a bug, just apache's own
rules of precedence for handling files that match multiple extensions/mime-types.
a recent post on bugtraq hilighted an issue with how upstream has configured apache to invoke php, namely using addhandler, which has the behavior of matching the extension anywhere in the file. this means that foo.php.jpg will be run as php. where this becomes an issue is web apps that allow uploads into the webspace for images, pdfs, etc. if the app assumes that anything.jpg is safe, this addhandler feature will surprise it.
Hi Joe,
Are you sure this is limited to just CentOS? I've seen that config used before on other distro's apache configs.
i'm sure other distros use the same method, but i don't use any and this is the centos list, so that's all i'm talking about.
From the Apache 2.x Docs:
Care should be taken when a file with multiple extensions gets associated with both a MIME-type and a handler. This will usually result in the request being by the module associated with the handler. For example, if the .imap extension is mapped to the handler imap-file (from mod_imap) and the .html extension is mapped to the MIME-type text/html, then the file world.imap.html will be associated with both the imap-file handler and text/html MIME-type. When it is processed, the imap-file handler will be used, and so it will be treated as a mod_imap imagemap file.
So if example.php.gif is read by apache, the AddHandler for php5-script (mod_php) will take precedence over the mime-type handler for .gif (image/gif) and the file will be treated as a php script.
From that it almost sounds like it's not a bug, just apache's own
rules of precedence for handling files that match multiple extensions/mime-types.
i can understand why apache has this behaviour, but i think the bug is using it for handlers that can execute code. since the expected behaviour can be obtained more safely with the filesmatch mechanism, it sure seems like an obvious change.
Joe Pruett wrote:
a fix is to replace two lines in /etc/httpd/conf.d/php.conf:
AddHandler php5-script .php AddType text/html .php
what about other AddHandlers ?
for instance,
AddHandler cgi-script .cgi
AddHandler type-map var
I had both of these on my server, and just now replaced them with similar <FilesMatch...> sections.
John R Pierce wrote on Sun, 15 Nov 2009 12:26:08 -0800:
I had both of these on my server, and just now replaced them with similar <FilesMatch...> sections.
Just a comment about the FilesMatch thing. The proposed additional ForceType will not work in there according to the httpd docs. Not that this makes a big difference.
Kai
I had both of these on my server, and just now replaced them with similar <FilesMatch...> sections.
Just a comment about the FilesMatch thing. The proposed additional ForceType will not work in there according to the httpd docs. Not that this makes a big difference.
what in the docs are you reading to indicate forcetype won't work? i just put that in to match the addtype clause i removed. i didn't even check to see if the php module sets the type to text/html by default already.
Joe Pruett wrote on Mon, 16 Nov 2009 08:43:41 -0800 (PST):
what in the docs are you reading to indicate forcetype won't work?
http://httpd.apache.org/docs/2.2/mod/core.html#forcetype says it works only if given in directory-type context and that's unlikely to happen here. You would rather set the FilesMatch global.
i just
put that in to match the addtype clause i removed. i didn't even check to see if the php module sets the type to text/html by default already.
it does, but you can override it. I guess you can*not* override Forcetype, which might be a problem. Many PHP outputs will not be text.
I think the AddType can stay there just fine. It's the AddHandler directive that creates the problem. And one may rather consider this a bug in httpd. AFAIK, the multiple extension handling is mostly there to allow content negotiation. If so, then this functionality should be limited to the options that are available to content-negotiation in that given configuration - e.g. php.en php.es and not to any "unknown" string.
Kai
what in the docs are you reading to indicate forcetype won't work?
http://httpd.apache.org/docs/2.2/mod/core.html#forcetype says it works only if given in directory-type context and that's unlikely to happen here. You would rather set the FilesMatch global.
i think that directory context is not just <Directory>, and the text at the url says the directive may be placed in <directory>, <location>, or <files> which i assume means <filesmatch> as well.
i just
put that in to match the addtype clause i removed. i didn't even check to see if the php module sets the type to text/html by default already.
it does, but you can override it. I guess you can*not* override Forcetype, which might be a problem. Many PHP outputs will not be text.
i did some more testing and i was able to override the forcetype (if it truly is working) via header('content-type'), like you'd do for serving images via php. i guess i haven't tested without forcetype yet...
I think the AddType can stay there just fine. It's the AddHandler directive that creates the problem. And one may rather consider this a bug in httpd. AFAIK, the multiple extension handling is mostly there to allow content negotiation. If so, then this functionality should be limited to the options that are available to content-negotiation in that given configuration - e.g. php.en php.es and not to any "unknown" string.
right, the reason is to allow foo.en.html or foo.html.en. i'm not sure i agree that is good, but for simple text conditionals it is fine. using it for php is just bad.
Joe Pruett wrote on Wed, 18 Nov 2009 09:39:30 -0800 (PST):
i think that directory context is not just <Directory>, and the text at the url says the directive may be placed in <directory>, <location>, or <files> which i assume means <filesmatch> as well.
Right. I was getting the German version of this page and I swear it didn't include the <Files> thing last time I looked. Now it does. And it looks like it has been added during the last days as it is still missing an "or". So, you are right, yes.
i did some more testing and i was able to override the forcetype (if it truly is working) via header('content-type'), like you'd do for serving images via php. i guess i haven't tested without forcetype yet...
Thanks for the info. Still, I think you can keep the AddType directive and not use ForceType because the problem is only the AddHandler directive that overrides the mime-type for the image.
Kai
i have reported this upstream. hopefully they will see it as a problem and address it.
For those of you who are interested, the upstream bug is https://bugzilla.redhat.com/show_bug.cgi?id=537535
Please comment as appropriate.
-
Drew -
Jim Perrin -
Joe Pruett -
John R Pierce -
Kai Schaetzl