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...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: php
Version: 6.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Remi Collet
QA Contact: BaseOS QE - Apps
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:
Last Closed: 2013-01-14 09:17:55 UTC
Target Upstream Version:

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:


  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

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.