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
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.
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
(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.
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
This is corrected in upstream 5.3.7: http://www.php.net/archive/2011.php#id2011-08-18-1
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.
(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?
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."
(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".
Thanks, I'll pass that along to my auditors and see if it is an accepted explanation.
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
Statement: (none)
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.
(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.
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
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