Description of problem:
Default php configuration uses the following to instruct httpd to process files with .php extension via php:
AddHandler php5-script .php
AddType text/html .php
This will, however, enable processing via php even for files that have multiple extensions with .php not being the last, such as image.php.jpg. This may create a risk for users that allow file uploads of certain file types, but do not configure upload directories correctly to prevent php script execution form there.
PHP documentation now recommends using FilesMatch + SetHandler to make it less likely for users to create insecure configuration due to this:
Tell Apache to parse certain extensions as PHP. For example, let's have
Apache parse .php files as PHP. Instead of only using the Apache AddType
directive, we want to avoid potentially dangerous uploads and created files
such as exploit.php.jpg from being executed as PHP. Using this example, you
could have any extension(s) parse as PHP by simply adding them. We'll add
.php to demonstrate.
Just wanted to add support for this idea. The current configuration is a security problem.
I would also like to support this idea! We are starting to see more and more exploits under .php.jpg being used.
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
We can encounter some cases where this change will break the current configuration.
When the default php handler is overridden per virtual host configuration (RemoveHandler / AddHandler), as FilesMatch is evaluated after the vhost / directory directives and is set globally it will stay active and the expected new handler will not work as expected (with current php.conf).
Should we provide an update which could break some configuration ?
> Should we provide an update which could break some configuration ?
As this relates to a serious security issue, yes I think it is important enough to create this situation.
Obviously the corresponding errata notice should highlight that this potential scenario exists (e.g. encourage applicable environments to use FilesMatch in vhost directives; according to Apache docs this is a perfectly valid configuration, so it could be swapped out there as well where such configurations were added).
I don't think it's appropriate to have new RHEL deployments, deployed today, created with a configuration which contains this security problem by default. We should try to make sure the default configuration is as secure as possible...
Per comments above, this change has been shown to break existing configurations. Given that the security impact of this change is small, and limited to mitigating poor user configuration, we don't plan to implement this change in an update to the php package for Red Hat Enterprise Linux 6.
We do plan to change the default configuration in future major releases of RHEL to reflect this.