Bug 1116662 (CVE-2014-4721)

Summary: CVE-2014-4721 php: type confusion issue in phpinfo() leading to information leak
Product: [Other] Security Response Reporter: Murray McAllister <mmcallis>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: carnil, fedora, jorton, jrusnack, logan, mmaslano, patrick.d.mayo, rcollet, redhat-bugzilla, robert.scheck, s.kieske, tis, webstack-team
Target Milestone: ---Keywords: Reopened, Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: php 5.4.30, php 5.5.14 Doc Type: Bug Fix
Doc Text:
A type confusion issue was found in PHP's phpinfo() function. A malicious script author could possibly use this flaw to disclose certain portions of server memory.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-08 02:33:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1080180, 1114521, 1116532, 1116663, 1119563, 1120503, 1120504, 1120981, 1149762, 1149771    
Bug Blocks: 1065838, 1114158, 1149858    

Description Murray McAllister 2014-07-07 01:41:57 UTC
Stefan Esser discovered a type confusion issue affecting phpinfo(). Setting certain variables before running phpinfo() could allow a local attacker to leak memory from an arbitrary location. This could be an issue remotely in shared hosting environments if PHP code can be injected. The following post demonstrates reading an SSL private key in an environment using PHP 5.3, mod_php,  and mod_ssl:

https://www.sektioneins.de/en/blog/14-07-04-phpinfo-infoleak.html

References:
https://bugs.php.net/bug.php?id=67498
http://git.php.net/?p=php-src.git;a=commitdiff;h=3804c0d00fa6e629173fb1c8c61f8f88d5fe39b9

Comment 2 Murray McAllister 2014-07-07 01:44:47 UTC
Created php tracking bugs for this issue:

Affects: fedora-all [bug 1116663]

Comment 4 Huzaifa S. Sidhpurwala 2014-07-07 08:39:06 UTC
*** Bug 1116532 has been marked as a duplicate of this bug. ***

Comment 5 Huzaifa S. Sidhpurwala 2014-07-07 09:00:47 UTC
In order to successfully exploit this flaw, the script author needs to set one of the php variables used by the phpinfo() function (PHP_SELF, PHP_AUTH_TYPE, PHP_AUTH_USER and PHP_AUTH_PW) with a malicious/specially-crafted value, before calling the phpinfo() function.

This can only be done by the script author, hence this issue could only be exploited if the script author creates a specially-crafted script to be executed by the caller of phpinfo(). For example as mentioned in the blog link associated with comment #0:

<?php
   $PHP_SELF = 0x55555555;
   phpinfo(INFO_VARIABLES);
?>

Secondly, it is not recommended to have a public-facing phpinfo() page, irrespective of the current bug in its implementation, it exposes a lot of information about the php installation and the underlying Operating system, which could be used to elevate other possible flaws in a php application.

Comment 7 Loganaden Velvindron 2014-07-07 09:13:44 UTC
(In reply to Huzaifa S. Sidhpurwala from comment #5)
> In order to successfully exploit this flaw, the script author needs to set
> one of the php variables used by the phpinfo() function (PHP_SELF,
> PHP_AUTH_TYPE, PHP_AUTH_USER and PHP_AUTH_PW) with a
> malicious/specially-crafted value, before calling the phpinfo() function.
> 
> This can only be done by the script author, hence this issue could only be
> exploited if the script author creates a specially-crafted script to be
> executed by the caller of phpinfo(). For example as mentioned in the blog
> link associated with comment #0:

It can be used in conjunction with vulnerabilities in PHP web applications themselves.

E.g During the weekend, we received a report saying that 

(URL:http://blog.sucuri.net/2014/07/remote-file-upload-vulnerability-on-mailpoet-wysija-newsletters.html)

there's a remote file upload vulnerability. This can be used as a landing point to upload malicious php scripts, that can be used to steal private keys as Stefen demonstrated.

If a RedHat customer has many vhosts running on Apache/PHP 5.3, this can be a security issue.


> 
> <?php
>    $PHP_SELF = 0x55555555;
>    phpinfo(INFO_VARIABLES);
> ?>
> 
> Secondly, it is not recommended to have a public-facing phpinfo() page,
> irrespective of the current bug in its implementation, it exposes a lot of
> information about the php installation and the underlying Operating system,
> which could be used to elevate other possible flaws in a php application.

I've seen many deployment of Redhat & CentOS machines/VMs where phpinfo() is allowed.

Comment 9 Sven Kieske 2014-07-07 11:26:42 UTC
well, even if you think this is _not_ a security flaw, I don't
know why you close this as "not a bug", because it is clearly a bug.
it was fixed by upstream in other php versions.

So even if this is "just" a bug and no security bug (which I doubt, but I'm no
trained security expert), there should still be a fix, and even if you
don't fix it, this would just lead to "wontfix" instead of "not a bug".

I'm pretty sure that just fixing and testing it would need less time
than this whole debate.

Comment 10 Tuomo Soini 2014-07-07 12:09:59 UTC
I must disagree with security response team. Administrator is not only person who can add php code into system.

Comment 11 Josh Bressers 2014-07-07 18:08:28 UTC
Statement:

Red Hat classifies this as a security issue, however it is suggested that a properly secured PHP install should disable the phpinfo() function.

Comment 13 Francisco Alonso 2014-07-15 14:19:51 UTC
This issue affects the phpinfo implementation in ext/standard/info.c in Red Hat Enterprise Linux 6 and 7. A type confusion vulnerability was found in PHP versions before 5.4.30 and 5.5.x before 5.5.14. PHP does not check the string data type retrieved in the php_info_print_table_row() function for the PHP_AUTH_PW, PHP_AUTH_TYPE, PHP_AUTH_USER, and PHP_SELF variables. This might allow attackers to obtain sensitive information from process memory by using the integer data type with crafted values.

This issue can be mitigated by disabling the phpinfo() function in php.ini: 'disable_functions = phpinfo'

Comment 18 Martin Prpič 2014-07-28 11:12:55 UTC
IssueDescription:

A type confusion issue was found in PHP's phpinfo() function. A malicious script author could possibly use this flaw to disclose certain portions of server memory.

Comment 19 errata-xmlrpc 2014-08-06 05:15:40 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 5

Via RHSA-2014:1012 https://rhn.redhat.com/errata/RHSA-2014-1012.html

Comment 20 errata-xmlrpc 2014-08-06 06:06:13 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 7

Via RHSA-2014:1013 https://rhn.redhat.com/errata/RHSA-2014-1013.html

Comment 21 Murray McAllister 2014-08-06 12:19:46 UTC
Thanks to Loganaden Velvindron of elandsys.com for preparing the patch for this issue.

--
Murray McAllister / Red Hat Product Security

Comment 24 errata-xmlrpc 2014-10-30 19:46:26 UTC
This issue has been addressed in the following products:

  Red Hat Software Collections 1 for Red Hat Enterprise Linux 7
  Red Hat Software Collections 1 for Red Hat Enterprise Linux 6.5 EUS
  Red Hat Software Collections 1 for Red Hat Enterprise Linux 6.4 EUS
  Red Hat Software Collections 1 for Red Hat Enterprise Linux 6.6 EUS
  Red Hat Software Collections 1 for Red Hat Enterprise Linux 6

Via RHSA-2014:1766 https://rhn.redhat.com/errata/RHSA-2014-1766.html

Comment 25 errata-xmlrpc 2014-10-30 19:47:58 UTC
This issue has been addressed in the following products:

  Red Hat Software Collections 1 for Red Hat Enterprise Linux 7
  Red Hat Software Collections 1 for Red Hat Enterprise Linux 6.5 EUS
  Red Hat Software Collections 1 for Red Hat Enterprise Linux 6.4 EUS
  Red Hat Software Collections 1 for Red Hat Enterprise Linux 6.6 EUS
  Red Hat Software Collections 1 for Red Hat Enterprise Linux 6

Via RHSA-2014:1765 https://rhn.redhat.com/errata/RHSA-2014-1765.html