The Hardened-PHP Project of Germany is at it again. They found a bug in XML-RPC for PHP and PEAR XML_RPC. The project was looking for these kinds of problems in the libraries in a security audit they conducted because of previous flaws that had been found in these same PHP libraries earlier in the year.

Secunia rates the problem "highly critical" in its advisory on the subject. Also, the French Security Incident Response Team rated the flaw as "high-risk."

XML-based RPC (Remote Procedure Call) systems (which is what XML-RPC is an example of ) are used along with HTTP calls in Web services. They are used to allow execution of specified backend code routines which can then be used in the implementation of interactive services on a server. Blogging programs (and wiki generators) are the kinds of programs that make extensive use of these kinds of techniques.

Zend Core to offer Oracle-PHP integration. Click here to read more.

XML-RPC for PHP (later versions are also sometimes called by the jaw breaking acronym of PHPXMLRPC) and PEAR XML_RPC both use XML-RPC as their PHP scripting language, and are therefore vulnerable. When a library parses XMLRPC requests/repsonses, it constructs a string of PHP code that is later evaluated and executed.

What happened is that the project found a serious problem with the eval() function which could lead to the execution of arbitrary code. (Yes, patches are available. Version 1.2 of PHPXMLPRC and version 1.4.0 of PEAR XML_RPC are what you want to get in order to eliminate this problem.)

In this new problem, it seems that certain XML tags that are nested in parsed documents processed by the libraries are not being properly sanitized before being used in the "eval()" call. This has the result of user input being placed outside of the string delimiters within the evaluation string, and hence arbitrary code execution. This is what can be exploited by malicious persons, though no exploits in the wild have been reported as of this date.

To read more about the PHP consortium tackling third-party security issues, click here.

But the project is going beyond just reporting the vulnerability and issuing their own solution to the problem. They are trying to harden the libraries by writing them without any eval() calls at all.

The group's patch is described this way: "Hardening-Patch v0.4.1 was actually released one day after v0.4.0 because a few things were not handled properly within the eval() function black- and whitelist (callbacks, destructors, ...). Now every function or class that is defined during execution of eval()'d code is flagged as created_by_eval and if it is later used by the normal script (for example callbacks) they are handled as if executed from within eval()'d code."

It's interesting to me that they own up to their own implementation error in the patch. The fact that they caught it also speaks well of their technique.

PHP scripting is both ubiquitous and part of the unseen behind the screen workings that users don't notice. Keeping it clean is the security professional's responsibility, and it seems that they are up to the task.

This article was originally published on eWEEK.com.