Bugzilla – Bug 104403
VUL-0: CVE-2005-2498: new pear / RPC:XML problems
Last modified: 2021-11-03 15:10:52 UTC
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 <email@example.com>
Subject: [vendor-sec] XMLRPC is kinda public because of phpWiki maintainer
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.
This means the coordinated disclosure is blown. We are now creating packages and
will most probably release
updates in the next hours.
critical, since probably remote exploitable again.
cc poeml (for ampache)
Date: Sun, 14 Aug 2005 16:54:25 -0700
From: Karl Vollmer <firstname.lastname@example.org>
To: "Dr. Peter Poeml" <email@example.com>
Subject: Re: XMLRPC Exploit and Ampache Package
X-Spam-Status: No, hits=0.1 tagged_above=-20.0 required=5.0 tests=BAYES_50,
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
Lead Developer, Ampache.org
From: Stefan Esser <firstname.lastname@example.org>
To: email@example.com, firstname.lastname@example.org
Subject: [Full-disclosure] Advisory 15/2005: PHPXMLRPC Remote PHP Code
-= Security Advisory =-
Advisory: PHPXMLRPC Remote PHP Code Injection Vulnerability
Release Date: 2005/08/15
Last Modified: 2005/08/15
Author: Stefan Esser [email@example.com]
Application: PHPXMLRPC <= 1.1.1
Severity: A malformed XMLRPC request can result in execution
of arbitrary injected PHP code
Vendor Status: Vendor has released an updated version
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
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.
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.
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.
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
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
15. August 2005 - Public disclosure
We strongly recommend to upgrade to the vendor supplied new
version, that completely eliminates all calls to eval().
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 <firstname.lastname@example.org>
To: Stefan Esser <email@example.com>
Cc: Josh Bressers <firstname.lastname@example.org>, email@example.com
Subject: Re: [vendor-sec] PEAR:XMLRPC + phpxmlrpc round 2
On Fri, Aug 12, 2005 at 09:11:02PM +0200, Stefan Esser wrote:
> 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'] =
the base64_decode() call should not be there. The upstream XML_RPC
1.4.0 release doesn't seem to have this issue.
From: Stefan Esser <firstname.lastname@example.org>
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.
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
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.
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)