Bugzilla – Bug 94579
VUL-0: CVE-2005-1921: php XML RPC code injection
Last modified: 2021-11-08 16:41:33 UTC
Hello Petr, this one was sent to us via vendor-sec (not/semi public). php4, php5 and horde is affected. From: Stefan Esser <sesser@php.net> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) To: vendor-sec@lst.de Subject: [vendor-sec] PHP Applications + PEAR Serious Security holes Errors-To: vendor-sec-admin@lst.de Date: Wed, 29 Jun 2005 14:26:19 +0200 Hello, it has come to my attention, that the guys of Gulftech have started a totally irresponsible disclosure of a bug, that is know to me for quite a while. Now with soon every kiddie knowing about it, it is urgent to fix it: This bug allows injection of arbitrary PHP commands into eval() statements. PHP's PEAR::XML_RPC library is based on some very old code and there are actually 2 maintained versions of this code a) PEAR XML_RPC b) phpxmlrpc.sourceforge.net obviously Gulftech has only contacted the later one... Unfortunately you find one of these libraries bundled with a lot of PHP application: drupal, postnuke, serendipity, older wordpress, phpwiki, tikiwiki, ... And of course the PHP distribution comes with a pear commandline utility that uses this library to communicate with the pear server. The PEAR server itself is not vulnerable, because it uses a XMLRPC implementation that is not based on the same code. A fix for this bug is here: http://www.suspekt.org/RPC.php.diff and a trivial exploit that needs to get POSTed to the xmlrpc file is here: http://www.suspekt.org/rpc.txt The postNuke team has already posted an advisory on their site that give no details about this bug, but in the CVS of phpxmlrpc.sourceforge.net there is already Proof Of Concept code and a fix. And well I believe gulftech will release an advisory soon... The funny thing with this is that www.grsecurity.net runs a PHPWiki, that also uses this RPC library. Yours, Stefan Esser _______________________________________________ Vendor Security mailing list
CAN-2005-1921
>Can you forward that CVE id to the Gulftech people. I'd like to prevent >multiple CVE names getting assigned. > > > I can try. But I do not know a contact address yet. The whole thing is ugly, because obviously Gulftech contacted postNuke and the author of phpxmlrpc.php but not PHP.net Maybe they also contacted TikiWiki, Drupal etc... And waited for them to fix it, because there is no official Gulftech advisory yet. Only the PostNuke Authors wrote an advisory and now thanks to Secunia and co everyone know that there is a dangerous bug in XML_RPC. >Thanks for this heads up, it's appreciated as I think this issue is going >to be a bit ugly. > > It is already ugly and the PEAR developers have just released a fast update of XML_RPC. The Serendipity Developers have already provided an updated version. (But due to a bug in s9y < 0.8.2 the installed PEAR version is used instead of the bundled lib, so upgrading PEAR would have fixed it already) Stefan
Created attachment 40437 [details] RPC.php.diff RPC.php.diff
this is critical. we need fixes ASAP, but this should probably not block SP2.
SM-Tracker-1669
Which subpackages are affected? I've already prepared patchinfos with the list from last time. If additional packages are affected they need to be adapted.
hmm, second question is can one interject data into pear from remote? i thought pear itself is used only by the admin when called.
according to stefan esser it is not problematic for pear itself. horde appears not affected (has RPC.php, but this is from ext/xml I think), but Petr, please cross check. so, drop down to normal for now.
An exploit is available in the wild.
I checked horde and it is ok. php4 is affected in tarball BUILD/php-4.3.10/pear/packages/XML_RPC-1.1.0.tar php5 is affected in tarball BUILD/php-5.0.4/pear/packages/XML_RPC-1.2.2.tar Could some one take care about it? (I will be on vacation until 11.7. ;( )
SLES8 appears not to package XML_RPC. all others do.
fixed packages submitted to autobuild
php4-pear and php5-pear packages contain the fix
Created attachment 41293 [details] run with "php CAN-2005-1921-exploit.php" Had to remove one ) from the exploit to make it work. If it outputs lots of stuff php is exploitable. If it prints "no error" then the bug is fixed.
updates approved, advisory released
CVE-2005-1921: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)