PEAR XML_RPC remote code execution vulnerability [LWN.net]

July 6, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

A serious vulnerability in the PEAR XML_RPC library and the XML-RPC for PHP package has been disclosed. The vulnerability allows unsanitized data to be passed to the eval() call, which would allow execution of arbitrary PHP code.

The vulnerability was reported by James Bercegay of the GulfTech Security Research Team. Bercegay reports that the parseRequest() function passes data to eval() without sanitizing the input first. As a result, a properly-crafted XML file can be used to execute PHP code on the targeted server. Bercegay's advisory gives an example that could be used to execute the relatively harmless phpinfo() function to be executed on a target server:

<?xml version="1.0"?>
<methodCall>
<methodName>test.method</methodName>
  <params>
    <param>
      <value><name>','')); phpinfo(); exit;/*</name></value>
    </param>
  </params>
</methodCall>

PEAR's library or the XML-RPC for PHP package are used in a number of PHP-based projects, including WordPress, Drupal, PostNuke, Xaraya, phpGroupWare, Tikiwiki, and many others, which means that there are a lot of vulnerable servers out there. Users of PHP-based blogging applications and other packages that use XML_RPC should check to see if the software is vulnerable and update the package as soon as a new release is available. Some projects, like PostNuke, are advising users to remove the offending code altogether.

PEAR's XML_RPC library is also distributed with many Linux distributions. Most of the vulnerable projects and distributions have announced updated packages, and the PHP project has bundled the new PEAR XML_RPC package in PHP 4.4.0RC2, and a separate release is available on the PEAR site. The final PHP 4.4.0 release is scheduled for July 11. Users can also update the PEAR library by running "pear upgrade XML_RPC" as root or using sudo. An update of XML-RPC for PHP is also available.

Users should upgrade or take steps to remove the library as soon as possible, as it seems likely that exploits of this vulnerability will begin appearing in the wild soon, if they have not already.

(Log in to post comments)

PEAR XML_RPC remote code execution vulnerability

Posted Jul 8, 2005 16:23 UTC (Fri) by mtk77 (guest, #6040) [Link]

I am not usually a PHP-basher, but after reading the advisory, I cannot resist expressing concern about the quality of code in the PEAR and the calibre of people contributing to it, and what that says about the language, environment and supporting community of PHP in general.

A few, erm, "enthusiasts" aside, PHP is used for front-end web apps. What these people seem not to have realised is that every dynamic web page is a network service.

To adapt an OpenBSD motto, any "eval" is a security hole unless proven otherwise. (I am also inclined to observe that its use in this module forms a concise PHP-specific version of Tom Christensen's csh rant.) You don't have to be thinking of security holes all the time to see why passing input you didn't build up yourself to a function which can do literally anything that can be done in code is a bad idea.

PEAR XML_RPC remote code execution vulnerability

Posted Jul 18, 2005 13:10 UTC (Mon) by ggiunta (guest, #30983) [Link]

While I think it is not generally much useful to whine about other people's code quality without providing accurate bug reports (and possibly patches), I mostly agree with the previous comment about the PEAR repository.

Not 100% of the PEAR code is flawed, of course, but the quality varies wildly.

To make matters worse, the PEAR team thinks it's a good idea to import pre-existing libs into the repository, without asking explicit cooperation of the actual lib maintainers.
The benefits coming from a wider exposure of the code (since newbees tend to always use PHP code from PEAR, after all it's hosted on php.net, right?) and an auto-updater script are more than balanced by the impact of having to maintain two seaparate code forks, with separate bug reports etc...
Prominent examples of this situation are the XMLRPC (imported from phpxmlrpc) and SOAP (imported from NUSOAP) packages.

Having said that, the exposed bug has been sleeping in the code since circa 1999, and is not an artifact coming from the PEAR team. In 1999 security was less a concern in general and for PHP in particular (register_globalls=Off would coem much later).
I fully agree that rebuilding the code from scratch today, 'eval' would have to be banned, but hey, no one yet stepped up for the complete rewrite.

BTW: complete details about the problem and possible remedies are now online at http://phpxmlrpc.sourceforge.net#security