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
Created php tracking bugs for this issue: Affects: fedora-all [bug 1116663]
*** Bug 1116532 has been marked as a duplicate of this bug. ***
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.
(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.
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.
I must disagree with security response team. Administrator is not only person who can add php code into system.
Statement: Red Hat classifies this as a security issue, however it is suggested that a properly secured PHP install should disable the phpinfo() function.
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'
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.
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
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
Thanks to Loganaden Velvindron of elandsys.com for preparing the patch for this issue. -- Murray McAllister / Red Hat Product Security
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
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