Bugzilla – Full Text Bug Listing
|Summary:||VUL-0: CVE-2005-2498: new pear / RPC:XML problems|
|Product:||[Novell Products] SUSE Security Incidents||Reporter:||Marcus Meissner <meissner>|
|Component:||Incidents||Assignee:||Marcus Meissner <meissner>|
|Status:||RESOLVED FIXED||QA Contact:||Security Team bot <security-team>|
|Priority:||P5 - None||CC:||heiko.rommel, security-team|
|Whiteboard:||CVE-2005-2498: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N)|
|Found By:||Other||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
One of the patches via vendor-sec
the other patch from the same mail
modified exploit from last pear problem
Comment 1 Sebastian Krahmer 2005-08-15 05:57:36 UTC
Created attachment 46004 [details] One of the patches via vendor-sec ...
Comment 2 Sebastian Krahmer 2005-08-15 05:58:34 UTC
Created attachment 46005 [details] the other patch from the same mail ....
Comment 3 Sebastian Krahmer 2005-08-15 05:59:06 UTC
Date: Sun, 14 Aug 2005 22:15:34 +0200 From: Stefan Esser <email@example.com> To: firstname.lastname@example.org 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
Comment 4 Marcus Meissner 2005-08-15 08:47:51 UTC
Comment 5 Marcus Meissner 2005-08-15 11:41:43 UTC
critical, since probably remote exploitable again. cc poeml (for ampache)
Comment 6 Peter Poeml 2005-08-15 11:54:25 UTC
Date: Sun, 14 Aug 2005 16:54:25 -0700 From: Karl Vollmer <email@example.com> To: "Dr. Peter Poeml" <firstname.lastname@example.org> 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
Comment 7 Marcus Meissner 2005-08-15 13:00:21 UTC
From: Stefan Esser <email@example.com> To: firstname.lastname@example.org, email@example.com 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 [firstname.lastname@example.org] 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
Comment 8 Marcus Meissner 2005-08-15 16:04:43 UTC
Comment 9 Peter Poeml 2005-08-16 10:15:41 UTC
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.)
Comment 10 Marcus Meissner 2005-08-17 13:44:39 UTC
From: Joe Orton <email@example.com> To: Stefan Esser <firstname.lastname@example.org> Cc: Josh Bressers <email@example.com>, firstname.lastname@example.org 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
Comment 11 Marcus Meissner 2005-08-17 14:09:13 UTC
From: Stefan Esser <email@example.com> 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> ...
Comment 12 Petr Ostadal 2005-08-18 11:46:42 UTC
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.
Comment 14 Ludwig Nussel 2005-08-24 09:41:46 UTC
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.
Comment 15 Ludwig Nussel 2005-08-24 10:07:50 UTC
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.
Comment 16 Marcus Meissner 2005-08-24 11:13:26 UTC
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.
Comment 17 Petr Ostadal 2005-08-24 12:08:06 UTC
Comment 20 Marcus Meissner 2005-08-25 13:17:58 UTC
will redo patchinfos.
Comment 21 Marcus Meissner 2005-08-30 14:44:15 UTC
updates and advisory released. thanks!
Comment 22 Thomas Biege 2009-10-13 20:35:32 UTC
CVE-2005-2498: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N)