Bug 94579 (CVE-2005-1921)

Summary: VUL-0: CVE-2005-1921: php XML RPC code injection
Product: [Novell Products] SUSE Security Incidents Reporter: Thomas Biege <thomas>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Major    
Priority: P3 - Medium CC: patch-request, postadal, security-team
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: All   
Whiteboard: CVE-2005-1921: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: RPC.php.diff
run with "php CAN-2005-1921-exploit.php"

Description Thomas Biege 2005-06-29 15:09:49 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
Comment 1 Marcus Meissner 2005-06-29 15:18:43 UTC 
CAN-2005-1921
Comment 2 Marcus Meissner 2005-06-29 15:19:04 UTC 
>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
Comment 3 Marcus Meissner 2005-06-29 15:19:40 UTC 
Created attachment 40437 [details]
RPC.php.diff

RPC.php.diff
Comment 5 Marcus Meissner 2005-06-29 15:20:45 UTC 
this is critical. we need fixes ASAP, but this should probably not block SP2.
Comment 6 Thomas Biege 2005-06-29 15:27:51 UTC 
SM-Tracker-1669
Comment 7 Ludwig Nussel 2005-06-29 15:40:40 UTC 
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.
Comment 8 Marcus Meissner 2005-06-29 15:48:31 UTC 
hmm, second question is can one interject data into pear from remote? 
 
i thought pear itself is used only by the admin when called.
Comment 9 Marcus Meissner 2005-06-29 18:22:59 UTC 
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.
Comment 10 Thomas Biege 2005-07-01 06:55:48 UTC 
An exploit is available in the wild.
Comment 11 Petr Ostadal 2005-07-01 18:11:29 UTC 
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. ;( )
Comment 12 Marcus Meissner 2005-07-04 11:37:11 UTC 
SLES8 appears not to package XML_RPC.  
 
all others do.
Comment 13 Marcus Meissner 2005-07-05 08:22:22 UTC 
fixed packages submitted to autobuild
Comment 14 Marcus Meissner 2005-07-05 08:25:32 UTC 
php4-pear and php5-pear packages contain the fix
Comment 15 Ludwig Nussel 2005-07-07 08:13:51 UTC 
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.
Comment 16 Marcus Meissner 2005-07-08 16:42:45 UTC 
updates approved, advisory released
Comment 17 Thomas Biege 2009-10-13 21:30:03 UTC 
CVE-2005-1921: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)