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.
Bug 885839 - php: default to using safer FileMatch instead of AddType to enable PHP handling [rhel-6]
Summary: php: default to using safer FileMatch instead of AddType to enable PHP handli...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: php
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Remi Collet
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 838715
TreeView+ depends on / blocked
 
Reported: 2012-12-10 18:40 UTC by Tomas Hoger
Modified: 2021-01-14 09:23 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-14 09:17:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Tomas Hoger 2012-12-10 18:40:31 UTC
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>

Comment 3 Damien 2012-12-12 17:11:38 UTC
Just wanted to add support for this idea. The current configuration is a security problem.

Comment 4 Ionut B. 2012-12-12 22:24:01 UTC
I would also like to support this idea! We are starting to see more and more exploits under .php.jpg being used.

Comment 5 RHEL 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.

Comment 6 Remi Collet 2012-12-24 07:15:12 UTC
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 ?

Comment 7 Damien 2012-12-27 17:29:19 UTC
> 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...

Comment 9 Joe Orton 2013-01-14 09:17:55 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.