Slashdot Mirror
PHP Blogging Apps Open to XML-RPC Exploits
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."
From the command line:
pear clear-cache
pear upgrade XML_RPC
A blog server compromise cannot possibly lead to worse content.
No, PHPBB doesn't use either of the PHP XML RPC libraries that have been compromised because, well, PHPBB doesn't use XML at all.
wordpress released a fix for this on June 29. Changelog for 1.5.1.3
"...major Internet security event."
A euphemism if I've ever heard one. Can I think of a better euphemism?
"Wardrobe malfunction"
Ah, there it is.
"Live as if you'll die tomorrow." Ridiculous. You could die later today.
The Internet Storm Center Reports that a high pressure coding flaw in PHP has created an error mass large enough to cause a rotation in sysadmin heads and has issued a red hat/flag Internet surf warning for all surfing sites.
Well, Perl tends to be invulnerable to PHP flaws in the vast majority of situations.
Bingo...PHP has a very low barrier to entry. Add to that that it's mainly used in a networked environment, and you're going to have problems. You could code up this exact same problem in perl - the only difference is that by the time you knew enough to get input from the network into your script and passed to eval, you'd probably have had it beaten into you that it's a crime punishable with flogging.
There may be cultural differences at work here as well. XML-RPC is in PEAR and often recommended as a good way of implementing this kind of functionality. This isn't a bug-free guarantee, but there should be some minimal level of quality implied by that. Passing untrusted input directly to eval is gross negligence, and it sort of amazes me that no one noticed this before. I've read a lot of PHP and a lot of perl. It's easy to find crap, bug-riddled code in both. The main difference seems to be that crappy perl code isn't tolerated near so quickly. Crappy PHP code becomes a flagship application.
This is the voice of World Control. I bring you Peace.
Makes me sad that it's in PHP...since I love PHP
This isn't a PHP vulnerability. It's another poorly written, widely used application that's vulernable because the developer fails to check external input. The vulnerability is in a PHP script that someone has written. It could have been written in any langauge; the fault is on the developer, not PHP.
---John Holmes...
Thank goodness for suPHP:
http://www.suphp.org/Home.html
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.
BTW, suphp is my favorite way to check the overall status of an HP-UX system.
# suphp
Not much, runnin' some processes. 'Sup with you?
Visual IRC: Fast. Powerful. Free.
I read the vulnerability which links to the sourceforge.net page that has the source code of this "library". It's a PHP script that you include() into other PHP scripts to use the functions/methods defined. The developer of this PHP script used eval() in an incorrect manner.
Unless you have another article that shows the PHP XML-RPC Functions to be vulnerabile, this is not a PHP vulnerability.
---John Holmes...
Without being explicit, don't count your chickens if you're using Perl based CMSs. I'm aware of issues with at least one of the main Perl based CMSs which could ultimately lead to a full server compromise and am currently in talks with their developers about how to fix it. The last thing any sys admin, web developer or web site owner should do, is attempt to sit on their laurels. Yes, code will have bugs. Go forth and audit.
Tim Brown