Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
http://php.net/manual/en/install.unix.apache2.php
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.
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
I would also like to support this idea! We are starting to see more and more exploits under .php.jpg being used.
Comment 5RHEL Program Management
2012-12-16 06:49:14 UTC
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.