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
Worm anyone?
That I use Movable Type which won't be effected by this. Makes me sad that it's in PHP...since I love PHP. You can't have everything.
Blog: orange haired boy
God knows there's a ton of free (and probably poorly maintained) php boards out there.
A blog server compromise cannot possibly lead to worse content.
wordpress released a fix for this on June 29. Changelog for 1.5.1.3
I know when the same technique is used to compromise web sites with SQL in the back end it's called SQL injection. I guess this would be XML Injection? Or perhaps PHP Injection and XML is only the wrapper. XML Injection sounds cooler.
New wireless technology called XMax?
It could lead to more blogs!
blogging will lead to insane children
--
www.isnochys.com
"...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.
It always did. It always will.
I saw a request for phpmyadmin/index.php in one of my web server logs on July 1st around 4 AM EDT ..
..and in the couple years my web server has been up (somewhat aporadically though) i havent seen this request (just grepped the logs).
About 2 and a half hours ago i saw a request for phpmyadmin/index.php in my web server logs as well.
I dont have PHP or any forums installed
So my opinion is that this attack is in the wild. Can someone confirm?
This is a good idea, right?
Being funny is my sig nature.
This appears to be the same exploit that hackers used on cowboyneal.org a few months back.
Do you even lift?
These aren't the 'roids you're looking for.
I thought the high pressure region in PHP was responsible for fine weather but storms later.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Use alternatives!
Why not an app called Blosxom?
It's tiny Perl scripts.
Don't trust anyone under thirty.
For once I don't regret using slashcode then! I'm sure there must be other reasons...
I really don't want to bash PHP - it seems flexible. However, after having people break into my server through phpBB and Gallery, I replaced those apps with their mod_perl equivalents, and things are working faster and more secure. Having said that, it was hard to find the Perl equivalents and even hard to find good support for it (ie. themes, etc). I'm still looking for a good Gallery replacement written in Perl.
Obviously, security issues aren't always the language but usually come from the people who write it. It just seems to me that, since PHP is more popular for writing forums, image galleries, etc, that there are a lot more careless coders out there coding in PHP.
phpBB is a good example of this. Every other week, they have some security issue.
PostNuke has a serious security vulnerability? I am SOOOOO surprised!
Indeed, SQL injection attacks inject and run SQL commands, so this vulnerability would be a PHP Injection attack, as it's PHP code that gets executed on the server.
It seems like there's a lot of security advisories along these lines lately and they mostly seem to revolve around PHP site engines. Why PHP? Why not perl, or python, or Ruby?
Is there something about PHP that's making these things likely as opposed to some other language (which seems unlikely, there's plenty of simple mistakes you can make just as easily in perl, i.e. poor scrubbing of regexp/sql content), or is it just that there are more inexperienced people writing PHP code out there, or is it just that PHP site engines are getting installed by more security-inexperienced people, or are the PHP exploits getting publicized more, or am I just noticing them more?
What's going on here?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
If I read this correctly the venerability lies in how these blogging programs fetch RSS feeds from various places in that they don't check the input first. What are the chances that any popular blogs will link to sites likely to exploit this? And know how?
A worm is very unrealistic for the simple reason that blogging isn't popular enough and crossed linked well enough. Although there are junctions in blogging networks very few automated blogs pull from these areas, they are primarily designed for user use.
I'm sure this 'Internet Storm Centre' loved all this attention but it doesn't reflect on how good their alerts are or if there are any experts.
From the s9y forums:
http://www.s9y.org/forums/viewtopic.php?t=2034
Save yourself the hassle of doing a complete upgrade by simply downloading the new version an only copying the files from bundled-libs/XML/*
lol
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.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
it amazes me people still use that thing. Scary. Nasty. Creepy.
Should be forbidden from php.
Ironically, didn't the Windows Logo Certification forbid people from using "system"?
(ouch)
How *dare* an open-source product have bugs! This is exactly the reason that I threw my MSWin servers into the sea. Now you're expecting me to update my PHP libs? God almighty, you're all the same.
The biggest problem I have always had with PHP is that it has never struck me like it was developed by a team and community that had any genuine sense of direction like the Perl and Python teams. IMO, what'd be a real coup for the Python community would be to really work on getting mod_python's PSP support distributed around to as many hosts as possible. It's a lot easier to write good code in Python than it is in PHP.
Click here or a puppy gets stomped!
And that's exactly why I use mod_perl for this kind of stuff. That and perl is a more flexible language
"...we should just trust our president in every decision that he makes and we should just support that." B.Spears 2003
kdedevelopers.org was hit by this flaw earlier today. And drupal's website no longer seems to have a list of drupal-using websites (I would suppose for this reason).
Normally I'd agree, but in this case, it's a PHP script written by someone else that's vulnerable. Any application using the xml-rpc server script (a plain old PHP script) is vulnerable becaus the developer didn't check user input.
---John Holmes...
This here's a 48 Magnum that'll blow your head right off. Now you gotta ask yourself one question, "Do I feel lucky?". Well, DO YA, PUNK?
XOOPS has released an updated version and patch on July 2'nd.
Old news travels fast ;)
http://drupal.org/drupal-4.6.2
Caution: May contain nuts.
phpBB has its own huge set of gaping security holes. :)
... that right above this article in /. is another article titled "Anatomy of a Hack" which basically describes how one can h4xx0r b0x3n?
As I've always thought, running PHP is the same as hanging a "Root Me" sign outside your server.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
Passing untrusted input directly to eval is gross negligence
I pass ALL fsk'ing data through strict purify scripts. Most data is assumed numeric and if'd to be >0 or forced to -10.
Man Slashdot has stupid filters but I guess they are needed... I just tried posting some PHP code to this comment and got this error: Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.
Well I guess that ends my post about purification. Sometimes you have too much of it and sometimes you don't have enough. Go figure.
The dangers of knowledge trigger emotional distress in human beings.
It is recommended that all admins deactivate and remove the 'xmlrpc' module within administration-modules and additionaly remove /xmlrpc.php and and the /modules/xmlrpc folder completly from the filesystem. .760 release will not contain the xml rpc library.
The PostNuke CMS Development Team highly recommends to *not* use the xml rpc library until the maintainers [1] provide a secure solution. Once an updated version is available a modularized version will be provided for download as an additional module.
Note: The upcoming
the dead shall rise, from their graves, to destroy, geometry.
So? A question. Would the vulnerability have been apparent, or the hack possible, without access to the blog source code?
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
I prefer a hot beef injection
YAZBS (Yet Another Zonk Blogging Story)
There is another kind of evil which we must fear most, and that is the indifference of good men. -- Boondock Saints
next version Deep Impact will be implemented on PHP+MYSQL...
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
Security Focus reports that if you are not using phpBB 2.0.16 or later, then you are vulnerable.
So if you subscribe to their list (which updated everyone as soon as this was known and fixed), you should have very little issue at all. Upgrades are available via "changed files only", "patch methods" or full upgrades, so please, let's go easy on the FUD eh?
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() 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() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.
Two further things that are disturbing about this exploit.
First looking at the diff which patched the exploit here, 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 and Edd Dumbill. Believe this and the Perl Frontier-RPC 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, 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 - 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, for example, are not beginners.
But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.
.. so it's always going to lag behind in that area, unfortunately.
- patch XML_RPC: "pear upgrade XML_RPC" should do the trick, or visit the distribution site for more details.
So why not run loose a spider that probes `pear upgrade XML_RPC`?
I'm a member of the support team for phpBB and deal with such things.
You're quite simply wrong.
Happily I've been using my homegrown XML-RPC library for PHP - mainly because Edd Dumbills version was unreadable and had an ugly API - and how dumb it looks use eval() on unchecked data?!
http://xprofile.berlios.de/