Bug 713194 (CVE-2011-2202)

Summary:	CVE-2011-2202 php: file path injection vulnerability in RFC1867 file upload filename
Product:	[Other] Security Response	Reporter:	Vincent Danen <vdanen>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:	David Kutálek <dkutalek>
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	ben.russo, cpugh, dkutalek, fedora, jorton, luke+redhat, rpm, wnefal+redhatbugzilla
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	php 5.3.7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-01-30 18:48:30 UTC	Type:	---
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:	740731, 740732, 740733, 740734, 768025, 769756, 769761, 831135
Bug Blocks:	713201, 715030, 750552

Description Vincent Danen 2011-06-14 15:51:09 UTC

It was reported [1] that PHP is prone to a security bypass, which could allow an attacker to upload and possibly overwrite files in the root directory on a vulnerable site.  PHP uses RFC1867 specifications to fill the $_FILES array from the multipart/form-data forms submitted to the server, where it attempts to remove the path component from the uploaded filename provided.  Due to an off-by-one error, when "/" or "" are present at the beginning of the request, and if there are no other occurrences of the slash or backslash character in the request, the first character is not removed, meaning that $_FILES['upload_field_name']['name'] may contain something like "/foo".  For a file to be overwritten, it must be writable by the user running the PHP script (typically the "apache" user).

All versions of PHP are affected by this flaw, and is has been fixed upstream [2].

[1] http://bugs.php.net/bug.php?id=54939
[2] http://svn.php.net/viewvc?view=revision&revision=312103

Comment 3 Tomas Hoger 2011-07-01 14:40:08 UTC

As noted above, this bug may cause file names in $_FILES array to contain an unexpected leading /.  If such file name is used to perform some operation on files without being prefixed with another target directory name, this can result in an attempt to access files directly in the root directory.  Creating or removing any file there would require root privileges.  Therefore, this issue has no real security impact where PHP scripts are run under dedicated web server user (such as default httpd's apache user).

Upstream bug notes this is relevant for Windows platform, where PHP is commonly run with system user privileges.

Comment 6 cpugh 2011-08-02 20:27:08 UTC

There is a patch that has been released.  Can you please implement it on a RHEL package update?  We need to patch against this.  

We just got new threat information from DOE stating that DOE web sites
are being attacked and compromised. The PHP issue below is one of the issues mentioned.
The link below lists this as IMPACT ASSESSMENT: High
http://www.doecirc.energy.gov/bulletins/t-647.shtml

Comment 7 Tomas Hoger 2011-08-03 07:31:12 UTC

(In reply to comment #6)
> There is a patch that has been released.  Can you please implement it on a RHEL
> package update?

This has been rated as having low impact for the reasons explained above.  We plan to include the patch in some future PHP packages update.

> We just got new threat information from DOE stating that DOE web sites
> are being attacked and compromised.

Are any details available?  Are Linux sites targeted?

> The link below lists this as IMPACT ASSESSMENT: High
> http://www.doecirc.energy.gov/bulletins/t-647.shtml

There does not seem to be further detail to explain the impact rating.  It may be the worst case (PHP running with system privileges) taking into an account, which does not apply to RHEL.

Comment 8 Tomas Hoger 2011-08-03 07:32:07 UTC

Reporter's blog post, with demo against PHP running as SYSTEM on Windows:
http://blog.kotowicz.net/2011/06/file-path-injection-in-php-536-file.html

Comment 9 Vincent Danen 2011-08-18 16:14:25 UTC

This is corrected in upstream 5.3.7:
http://www.php.net/archive/2011.php#id2011-08-18-1

Comment 10 Ben Russo 2011-09-19 10:39:45 UTC

The company that I work for has hundreds of RHEL servers, they have paid support contracts.  I would very much appreciate escalation of this issue within RedHat and ask that they release a patch ASAP.

The effect of the problem may be much lower on RHEL servers (where apache runs as user apache) than it is on Windows where by default PHP runs as local system account.  However even on Linux systems this bug could still have an effect since /tmp is world writable, /var/tmp is world writable, and directories such as /var/cache/mod_proxy, /var/cache/mod_ssl, /var/lib/dav are writable by user=apache.
/var/lib/php/session is writable by group=apache

At the very least this is a DOS attack as a REMOTE attacker could fill up the filesystems containing /var/tmp and /tmp.

Comment 11 Tomas Hoger 2011-09-19 14:33:56 UTC

(In reply to comment #10)
> The effect of the problem may be much lower on RHEL servers (where apache runs
> as user apache) than it is on Windows where by default PHP runs as local system
> account.  However even on Linux systems this bug could still have an effect
> since /tmp is world writable, /var/tmp is world writable, and directories such
> as /var/cache/mod_proxy, /var/cache/mod_ssl, /var/lib/dav are writable by
> user=apache.
> /var/lib/php/session is writable by group=apache
> 
> At the very least this is a DOS attack as a REMOTE attacker could fill up the
> filesystems containing /var/tmp and /tmp.

Ben, can you clarify what specific attack you have in mind?  This particular problem is about leading '/' not being stripped correctly form upload file names in the form "/filename", but not "/dir/filename".  Can you give an example how this could lead to filling one of the mentioned directories?

Comment 12 Ben Russo 2011-09-19 15:20:15 UTC

Thank you for the immediate reply!  :-)
The CVE-2011-2202 states that it allows absolute path TRAVERSAL and the ability to create or overwrite arbitrary files.
Am I reading it wrong? Does PHP strip all "/" except the first one?
If it is only the first "/" that is an issue, then I agree that this is not an important issue, and I can reply to my security auditing team with that information.

CVE-2011-2202
php: The rfc1867_post_handler function in main/rfc1867.c...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2202

Original
The rfc1867_post_handler function in main/rfc1867.c in PHP before 5.3.7 does not properly restrict filenames in multipart/form-data POST requests, which allows remote attackers to conduct absolute path traversal attacks, and possibly create or overwrite arbitrary files, via a crafted upload request, related to a "file path injection vulnerability."

Comment 13 Tomas Hoger 2011-09-19 18:20:46 UTC

(In reply to comment #12)
> Am I reading it wrong? Does PHP strip all "/" except the first one?
> If it is only the first "/" that is an issue, then I agree that this is not an
> important issue, and I can reply to my security auditing team with that
> information.

This bug is specific to handling of the special case of from "/filename".  Directory names are stripped from upload names as "dir/filename", "/dir/filename", or "../filename".

Comment 14 Ben Russo 2011-09-20 10:18:22 UTC

Thanks, I'll pass that along to my auditors and see if it is an accepted explanation.

Comment 17 errata-xmlrpc 2011-11-02 22:24:50 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 6

Via RHSA-2011:1423 https://rhn.redhat.com/errata/RHSA-2011-1423.html

Comment 18 Vincent Danen 2011-11-02 23:15:47 UTC

Statement:

(none)

Comment 21 Huzaifa S. Sidhpurwala 2012-01-17 04:11:39 UTC

This issue was fixed in php-5.3.7. It did not affect the version of php as shipped with Fedora-15 and Fedora-16.

Comment 22 Tomas Hoger 2012-01-17 08:38:17 UTC

(In reply to comment #21)
> This issue was fixed in php-5.3.7. It did not affect the version of php as
> shipped with Fedora-15 and Fedora-16.

It's probably less confusing to say that Fedora 15 and 16 are not affected by
this issue as they ship fixed upstream version.  F-15, however, included php
5.3.6 at GA and as this issue was first fixed upstream in 5.3.7, it probably was affected by this issue for some time.

Comment 23 errata-xmlrpc 2012-01-18 18:44:53 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2012:0033 https://rhn.redhat.com/errata/RHSA-2012-0033.html

Comment 24 errata-xmlrpc 2012-01-30 18:18:36 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2012:0071 https://rhn.redhat.com/errata/RHSA-2012-0071.html