Created attachment 46004 [details]
One of the patches via vendor-sec

...

Created attachment 46005 [details]
the other patch from the same mail

....

Date: Sun, 14 Aug 2005 22:15:34 +0200
From: Stefan Esser <sesser@php.net>
To: vendor-sec@lst.de
Subject: [vendor-sec] XMLRPC is kinda public because of phpWiki maintainer

Hello,

unfortunately I had to learn, that the phpWiki author has ignored my message
saying that he is only supposed to
test the patches and contact us. He prefered to write a public mail to
phpwiki-talk explaining his users, that
there is a new vulnerability and that they can find a patch in his CVS.

http://cvs.sourceforge.net/viewcvs.py/phpwiki/phpwiki/lib/XMLRPC/#dirlist

This means the coordinated disclosure is blown. We are now creating packages and
will most probably release
updates in the next hours.

Stefan Esser

CAN-2005-2498 

critical, since probably remote exploitable again.  
 
cc poeml (for ampache) 

Date: Sun, 14 Aug 2005 16:54:25 -0700
From: Karl Vollmer <karl.vollmer@gmail.com>
To: "Dr. Peter Poeml" <poeml@suse.de>
Subject: Re: XMLRPC Exploit and Ampache Package
X-Spam-Status: No, hits=0.1 tagged_above=-20.0 required=5.0 tests=BAYES_50,
 RCVD_BY_IP

Peter,

  There is yet another XML-RPC exploit that was just announced today.
The latest stable and development releases of ampache contain the
fixed libraries. There has already been an official release of
Pear:XMLRPC and hopefully a PHPXMLRPC release will follow soon. Please
let me know if you need any help or have any questions about this
latest patch.

-Karl
Lead Developer, Ampache.org

From: Stefan Esser <sesser@hardened-php.net> 
To: bugtraq@securityfocus.com, full-disclosure@lists.grok.org.uk 
Subject: [Full-disclosure] Advisory 15/2005: PHPXMLRPC Remote PHP Code 
        Injection Vulnerability 
 
 
 
                        Hardened-PHP Project 
                        www.hardened-php.net 
 
                      -= Security  Advisory =- 
 
 
     Advisory: PHPXMLRPC Remote PHP Code Injection Vulnerability 
 Release Date: 2005/08/15 
Last Modified: 2005/08/15 
       Author: Stefan Esser [sesser@hardened-php.net] 
 
  Application: PHPXMLRPC <= 1.1.1 
     Severity: A malformed XMLRPC request can result in execution 
               of arbitrary injected PHP code 
         Risk: Critical 
Vendor Status: Vendor has released an updated version 
   References: http://www.hardened-php.net/advisory_152005.67.html 
 
 
Overview: 
 
   PHPXMLRPC is the successor of Useful Inc's XML-RPC for PHP, which 
   is a PHP implementation of the XML-RPC protocol. 
 
   After Gulftech released their PHP code injection advisory in the 
   end of June 2005 we sheduled the code for an audit from our side. 
   Unfortunately we were able to find another vulnerability in the 
   XML-RPC libraries that allows injection of arbitrary PHP code 
   into eval() statements. 
 
   Unlike the last vulnerability this is not caused by wrongly 
   implemented escaping of the user input, but by an improper handling 
   of XMLRPC requests and responses that are malformed in a certain 
   way. 
 
   To get rid of this and future eval() injection vulnerabilities, the  
   Hardened-PHP Project has developed together with the maintainers 
   of both libraries a fix that completely eliminates the use of 
   eval() from the library. 
 
 
Details: 
 
   When the library parses XMLRPC requests/repsonses, it constructs 
   a string of PHP code, that is later evaluated. This means any 
   failure to properly handle the construction of this string can 
   result in arbitrary execution of PHP code. 
 
   In late June a problem was discovered, that certain XML tags where 
   using single quotes around embedded user input and single quotes 
   where not escaped. This allowed a typical injection attack. While 
   all these escaping problems were believed to be fixed, I was able 
   to find another problems, that allows injection of arbitrary code. 
 
   This new injection vulnerability is cause by not properly handling 
   the situation, when certain XML tags are nested in the parsed 
   document, that were never meant to be nested at all. This can be 
   easily exploited in a way, that user-input is placed outside of 
   string delimiters within the evaluation string, which obviously 
   results in arbitrary code execution. 
 
   Therefore we have added a XML tag nesting verification into the 
   code and additionally removed all call to eval(). Therefore the 
   resulting patch eliminates the current and the possibility for 
   future eval() holes. Additionally this means from the diff 
   between a vulnerable and a not vulnerable version it is not 
   possible to find the position of the flaw easily. 
 
 
CVE Information: 
 
   The Common Vulnerabilities and Exposures project (cve.mitre.org) 
   has assigned the name CAN-2005-2498 to this vulnerability.    
 
 
Proof of Concept: 
 
   The Hardened-PHP Project is not going to release an exploit for  
   this vulnerability to the public. 
 
 
Disclosure Timeline: 
 
   22. July   2005 - Contact with both library vendors established. 
                     Issue is discussed and a patch that eliminates 
                     the use of eval() is developed, improved and 
                     tested. 
   12. August 2005 - Affected applications are contacted and asked 
                     for beta test of the patches. 
   14. August 2005 - Vendors release bugfixed versions, after    
                     information about this vulnerability leaked  
                     through one of the affected applications to 
                     the public. 
   15. August 2005 - Public disclosure 
 
 
Recommendation: 
 
   We strongly recommend to upgrade to the vendor supplied new 
   version, that completely eliminates all calls to eval(). 
 
      PHPXMLRPC 1.2 
      http://prdownloads.sourceforge.net/phpxmlrpc/xmlrpc.1.2.tgz?download 
 
 
 

SM-Tracker-2059  

Regarding ampache, I will disable the xmlrpc functionality. (Last time
it was easy to fix but I don't want to spend time in testing with newer
xmlrpc library and I don't know anybody using the functionality anyway.
If anyone is dedicated enough to use it, they will use their own
installation of a newer ampache version anyway.)

From: Joe Orton <jorton@redhat.com> 
To: Stefan Esser <sesser@php.net> 
Cc: Josh Bressers <bressers@redhat.com>, vendor-sec@lst.de 
Subject: Re: [vendor-sec] PEAR:XMLRPC + phpxmlrpc round 2 
 
On Fri, Aug 12, 2005 at 09:11:02PM +0200, Stefan Esser wrote: 
> Hi, 
> 
> took me a little bit longer but here are the actual patches... 
 
Thanks a lot Stefan. 
 
We found one problem in testing the PEAR-XML.patch, the datetime.iso8601 
handling had a bug: 
 
+ 
+    case 'DATETIME.ISO8601': 
+        $XML_RPC_xh[$parser]['vt'] = $GLOBALS['XML_RPC_DateTime']; 
+       $XML_RPC_xh[$parser]['value'] = 
+base64_decode($XML_RPC_xh[$parser]['ac']); 
 
the base64_decode() call should not be there.  The upstream XML_RPC 
1.4.0 release doesn't seem to have this issue. 
 
Regards, 
 
joe 
 

From: Stefan Esser <sesser@php.net> 
 
Good catch. Well upstream is not affected because they mixed up my 
patches. They use the very first raw version of my patch. What I sent to 
you and the application developers was a better (but obviously broken in 
dateTime) patch, because it eliminates some array shifting operations. 
 
And yeah, now with the thing public I can tell you that exploiting this 
is as easy as embedding the following in an xmlrpc document. 
 
... 
<name><name>.phpinfo().</name></name> 
or 
<name><base64>.phpinfo().</base64></name> 
... 
 

I backported patch for all affected distros.

Package mod_php4 in sles8 does not contain affected files.

I fixed 9.0 (mod_php4), 9.1 and sles9 (php4), 9.2 (php4), 9.3 (php4), 9.3 (php5)
and stable (php4).

I am working on fix for php5 in stable.

Created attachment 47336 [details]
modified exploit from last pear problem

The unfixed version dumps lots of crap to stdout. The fixed version gives an
error. This indicates that something has been fixed, it's no guarantee that the
hole is really completely fixed though.

Petr the php packages on 9.1/sles9 are broken. You need to patch the manifest  
file or something like that otherwise an md5sum check fails. Check the build  
logs. Since you need to touch the package again now you could probably include 
the pcre fixes as well. 

i had this patched in the last xmlrpc update ... in the toplevel 
is a "package.xml" file with md5sums... you need to adapt the 
md5sums. 
 
I vaguely remember that this was only a problem for 9.1/SLES9. 
 
Petr, we are going to reissue this, so please apply the system pcre 
fix if possible, otherwise the pcre patch. 

ok

to comment #16 :same problem was with 9.0 ;(

Fixed and submited with fixes of bug #112645

will redo patchinfos. 

updates and advisory released. thanks! 

CVE-2005-2498: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N)