PHP Blogging Apps Open to XML-RPC Exploits 166
miller60 writes "A bunch of popular PHP-based blogging and content management apps are vulnerable to a security hole in the PHP libraries handling XML-RPC, which could allow a server compromise. Affected apps include Wordpress, Drupal, PostNuke, Serendipity, phpAdsNew, phpWiki and many more. The presence of the security hole in a large number of programs is among the factors leading the Internet Storm Center to warn that the environment is ripe for a major Internet security event."
How to patch PHP/PEAR (Score:5, Informative)
pear clear-cache
pear upgrade XML_RPC
Question: does this effect phpbb? (Score:4, Informative)
Re:Question: does this effect phpbb? (Score:5, Informative)
this is news? (Score:5, Informative)
On the insecurity of PHP blogging (Score:2, Informative)
Why not an app called Blosxom? [blosxom.com]
It's tiny Perl scripts.
Re:Question: does this effect phpbb? (Score:1, Informative)
In the wild? (Score:3, Informative)
and...
So my opinion is that this attack is in the wild. Can someone confirm?
Probably just some script kiddie looking for a phpMyAdmin install not behind a password.
Re:Don't want to bash PHP.... (Score:3, Informative)
This is necessary because mod_php runs scripts as the same user who started httpd, usually "nobody", so any files you want your PHP scripts to write to has to be world-writable. The problem would go away if mod_php could just run PHP scripts as their owners, instead of as the user running httpd!
You can already install suphp to do this, but you pay a performance penalty, since it has to start a new process for each invocation.
mod_php's advantage is that it runs scripts in the httpd process, so of course they have the same permissions as the user running httpd. But it could be changed: spawn a new process for each unique user who owns a PHP script (setuid to that user), and have the main httpd process communicate to the appropriate user's child process via a local socket whenever it's time to run one of their scripts. Then you only have to spawn one process for each user, and once that's done, the scripts could run just as fast as they do now.
Re:How to patch PHP/PEAR (Score:4, Informative)
server bin #
downloading XML_RPC-1.3.1.tgz
Starting to download XML_RPC-1.3.1.tgz (25,310 bytes)
upgrade ok: XML_RPC 1.3.1
Re:Don't want to bash PHP.... (Score:5, Informative)
http://www.suphp.org/Home.html [suphp.org]
My host uses this, so I don't need world-readable files and directories in my
~/www/ directories for each site. The webserver may run as nobody, but the
PHP scripts run as the same user I log in as to upload the files.
Re:i was hacked yesterday (Score:3, Informative)
Re:i was hacked yesterday (Score:1, Informative)
Wiping your hard drive is very Windows.
Maybe so, but in this situation it's also very right. If you have no way to verify any executables, you can't trust them.
BTW, it's easier to start with something that's already locked down [openbsd.org].
Re:Makes me happy (Score:5, Informative)
Unless you have another article that shows the PHP XML-RPC Functions [php.net] to be vulnerabile, this is not a PHP vulnerability.
---John Holmes...
Re:... lucky (Score:3, Informative)
Of all things to misquote, don't misquote Dirty Harry!
"I know what you're thinking: "Did he fire six shots, or only five?" Well, to tell you the truth in all this excitement, I've kinda lost track myself. But, being this is a
Lessons to be learnt? (Score:2, Informative)
Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.
From a design perspective, it's really bizarre the way they've chosen to use eval() [php.net] in the first place.
For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.
You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() [php.net] to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP [incutio.com], for example, and there are others [keithdevens.com] to chose from.
Two further things that are disturbing about this exploit.
First looking at the diff which patched the exploit here [php.net], all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.
Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc [usefulinc.com] and Edd Dumbill [usefulinc.com]. Believe this and the Perl Frontier-RPC [uwinnipeg.ca] libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.
This exploint has taken a very long time to spot. Looking at the main projects CVS here [sourceforge.net], with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.
These days Usefulinc are doing things Gnome related [usefulinc.com] - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.
What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR [php.net], for example, are not beginners.
But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.