Bug 885839

Summary:	php: default to using safer FileMatch instead of AddType to enable PHP handling [rhel-6]
Product:	Red Hat Enterprise Linux 6	Reporter:	Tomas Hoger <thoger>
Component:	php	Assignee:	Remi Collet <rcollet>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE - Apps <qe-baseos-apps>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	elonex, jorton, rcollet, uk.damien
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-14 09:17:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	838715

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.