![The Internet The Internet](http://a.fsdn.com/sd/topics/internet_64.png)
![Security Security](http://a.fsdn.com/sd/topics/security_64.png)
![PHP PHP](http://a.fsdn.com/sd/topics/php_64.png)
![Programming Programming](http://a.fsdn.com/sd/topics/programming_64.png)
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
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:How to patch PHP/PEAR (Score:2)
[root@server2 ~]# pear clear-cache
I'm not sure why it doesn't like my ldap library. I've tried uninstalling, reinstalling, etc. Running FC3.
I actually have PHP pages though.
Re:How to patch PHP/PEAR (Score:2)
Re:How to patch PHP/PEAR (Score:2)
Re:How to patch PHP/PEAR (Score:2)
Oh wait, Debian's security support is still broken. Never mind.
Makes me happy (Score:3, Interesting)
Re:Makes me happy (Score:1)
Re:Makes me happy (Score:5, Funny)
Re:Makes me happy (Score:1)
Re:Makes me happy (Score:2)
Re:Makes me happy (Score:5, Insightful)
---John Holmes...
Re:Makes me happy (Score:1)
Re:Makes me happy (Score:3, Interesting)
What's sad is that a default lib makes such a bad mistake. It uses eval on a string that's generated from user input. It doesn't matter how good you check the user-input, there's always one way for the user to bypass them. Someone needs to review the pear-code for such stupid mistakes.
b4n
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...
Open Source? (Score:2)
Re:Open Source? (Score:2)
Re:Open Source? (Score:2)
Re:Open Source? (Score:2)
Re:Open Source? (Score:2)
Considering the number of security vulnerabilities found in closed source applications and systems, yes, it would most likely have been discovered at some point.
I suggest you follow bugtraq for a few months.
Question: does this effect phpbb? (Score:4, Informative)
Re:Question: does this effect phpbb? (Score:5, Informative)
Re:Question: does this effect phpbb? (Score:2)
What I do know is that I once found a flaw in another PHP board I won't name and rather than fix it, I was told by the developers that they don't consider it a bug. Now, g
Re:Question: does this effect phpbb? (Score:1)
b4n
Re:Question: does this effect phpbb? (Score:1, Informative)
Re:Question: does this effect phpbb? (Score:2)
http://www.phpfreaks.com/articles/245/0.php [phpfreaks.com]
nope (Score:2)
How is this a problem? (Score:5, Funny)
Here's how (Score:3, Funny)
Re:How is this a problem? (Score:1)
A blog server compromise cannot possibly lead to worse content.
Good point:this is news? (Score:5, Informative)
Re:this is news? (Score:2)
Re:this is news? (Score:2)
Obviously, those Black Hats who wanted to know this stuff would already know it. The early release of this information to PHP-based developers did, however, limit the damage done by worms based on the exploit (see PHPBB exploit in December 2004).
Re:this is news? (Score:1)
Re:this is news? (Score:1)
http://www.php.net/ [php.net] had a news entry about the issue last week. So everyone should have patched their pear-libs in the meanwhile.
b4n
Wouldn't This Be Called an XML Injection Attack? (Score:3, Interesting)
New wireless technology called XMax? [whattofix.com]
Re:Wouldn't This Be Called an XML Injection Attack (Score:1)
unhealthy (Score:1, Offtopic)
--
www.isnochys.com
Choice of words (Score:5, Funny)
A euphemism if I've ever heard one. Can I think of a better euphemism?
"Wardrobe malfunction"
Ah, there it is.
Re:Choice of words (Score:1)
I hear sirens. Wooo. Woooo. Woo wooo. (Score:5, Funny)
Re:I hear sirens. Wooo. Woooo. Woo wooo. (Score:2)
noticed something in my webserver logs (Score:2, Interesting)
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?
Re:noticed something in my webserver logs (Score:1)
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:In the wild? (Score:2)
And, the phpmyadmin documentation for as long as I can remember has said DONT USE PHPMYADMIN for the directory.
Even a directory called admin is a very bad idea.
Re:noticed something in my webserver logs (Score:1)
as far as it being "in the wild" since the web page explains exactly how to perform it in a few lines of code, that should qualify as in the wild.
i was hacked yesterday (Score:2, Funny)
This appears to be the same exploit that hackers used on cowboyneal.org a few months back.
Re:i was hacked yesterday (Score:4, Insightful)
not quite got a handle on locking your box down so your web server can only write to specific directories huh, well, you might learn now.
Not running your webserver chrooted ? well, you might learn now.
Wiping your hard drive is very Windows.
Re:i was hacked yesterday (Score:2, Funny)
Pentium II.. Gentoo.. Wiped.
Ouch. I wouldn't wanna' watch him reinstall that.
Re:i was hacked yesterday (Score:2)
Re:i was hacked yesterday (Score:3, Informative)
Re:i was hacked yesterday (Score:2)
On the insecurity of PHP blogging (Score:2, Informative)
Why not an app called Blosxom? [blosxom.com]
It's tiny Perl scripts.
Re:On the insecurity of PHP blogging (Score:2)
slashcode it is then (Score:2)
Don't want to bash PHP.... (Score:4, Interesting)
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.
Re:Don't want to bash PHP.... (Score:2)
I can only say that I was shocked in the first one, I was battle hardened by the time I untarred number two.
sql injection & register_globals were my favourite finds.
"you need to have your files set to chmod 777 for this to work" is another pearler.
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 invocati
Re:Don't want to bash PHP.... (Score:2)
Re:Don't want to bash PHP.... (Score:2)
Re:Don't want to bash PHP.... (Score:2)
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:Don't want to bash PHP.... (Score:5, Funny)
# suphp
Not much, runnin' some processes. 'Sup with you?
Re:Don't want to bash PHP.... (Score:2)
--ajay
Re:Don't want to bash PHP.... (Score:2)
Re:Don't want to bash PHP.... (Score:2)
That's wrong. They only need to be writable by the user running httpd.
The problem would go away if mod_php could just run PHP scripts as their owners, instead of as the user running httpd!
This is even worse. I don't want any root suid httpd process in my system, do you?.
You can already install suphp to do this, but
Re:Don't want to bash PHP.... (Score:2)
The distinction is only important if your sysadmin is kind enough to chown or chgrp the files for you. Otherwise, since httpd is probably running as nobody/nogroup and you're probably not in nogroup, your only choice is to make them o+w.
And even if you can make them writable only by the user running httpd, that still means anyone else who shares the web server can overwrite your files, because their scripts run with the same permission
Re:Don't want to bash PHP.... (Score:2)
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!
There's an answer for this - Metux MPM [metux.de] and it allows Apache to run as any user that owns the site with minimal performance degredation. (Obviously, there is SOME degredation!)
Unlike SuPHP, which runs a separate
Re:Don't want to bash PHP.... (Score:2)
The problem would go away if mod_php could just run PHP scripts as their owners, instead of as the user running httpd!
This is a simple permissions problem that's common to many unix apps. chmod 0777 is rarely the right answer to the problem (it's like swatting a fly with a sledgehammer).
It's often easier to simply chown the directory containing the scripts to the web server's user. That way, local users cannot use that web directory illicitly.
The suid stuff for php and mod_perl is kind of crap. M
Re:Don't want to bash PHP.... (Score:2, Funny)
The reason that noone's hacked the Perl equivs. is that not even the hackers want to code in Perl.
(Jus' trolling. I'd write in BrainFuck [muppetlabs.com] over Perl.)
Re:Don't want to bash PHP.... (Score:4, Insightful)
Exactly. And, this is a very important point that all the Perl / Ruby / Python / Whatever FANBOYS like to ignore.
phpBB is a good example of this. Every other week, they have some security issue.
Come on now, you know very well that's an exageration.
Re:Don't want to bash PHP.... (Score:1, Insightful)
Come on now, you know very well that's an exageration.
Seriously, at least once a week.
PHP definitely needs to be less ad hoc (Score:2)
Re:Don't want to bash PHP.... (Score:2)
Choose G2 (Gallery 2), you will notice that it's a whole new application. It has no code in common with Gallery 1. And all inputs are checked thorougly.
It's the cleanest PHP code I've ever seen. No spaghetti code. See: G2 Development Guidelines [menalto.com]. (G2 is almost finished, it's in its last beta cycle)
Re:Don't want to bash PHP.... (Score:1)
there are a lot more careless coders out there coding in PHP.
That's exactly the issue. This isn't a PHP vulnerability. It's a poorly written script that doesn't check input properly.
It annoys me to see PHP blamed for stuff like this when it's poor programmers that should be blamed. PHP is just easy to learn, so there are a lot of bad programmers out there creating scripts like this.
I can't honestly say the xml-rpc scripts are bad because of this one issue, though, as I've never used it and only look
Re:Don't want to bash PHP.... (Score:4, Insightful)
To make an analogy, let's look at C. The C language was invented for systems programming, and it excels in that role -- C has been the language of choice for low level hacking for 20+ years. There's a damn good reason that OS kernels and device drivers are written in C -- it gives an expert programmer near-total control of the hardware.
However, this very power is C's downfall when it's used for general application programming. In the hands of anyone other than an expert, C is dangerous because it places too much demand on the programmer to do things "the right way", rather than preventing those errors from ever happening in the first place. It's trivially easy to introduce a buffer overflow or a memory leak into a C program, because the language intentionally does not do bounds checking or garbage collection. Languages which are intended for developing applications include these features -- they intentionally introduce run-time overhead so that the programmer can concentrate his attention on the application's logic rather than working around the language's shortcomings.
Having to manually write code to check each and every user input in an application is a horribly inefficent use of programmer time, and is prone to errors of omission. The development process is FAR more efficent if the language does this kind of housekeeping for the programmer automatically and transparently. This principle is doubly true for a scripting language like PHP, which is intended to be used by people who don't have a solid software engineering background.
Re:Don't want to bash PHP.... (Score:2)
Yep. Just because everyone else is doing it, doesn't make it right.
For both POST and GET, user input from a web form is, by definition, passed to your program as a URL-encoded string. In order to use that string in your program, it has to be decoded, parsed out into name-value pairs, and then be assigned to the appropriate user variables and/or objects. There's ample opportunity to validate the input in thi
Re:Don't want to bash PHP.... (Score:2, Interesting)
I really don't want to bash PHP - it seems flexible.
You should bash PHP. It's an awful language. I don't think I'd call it flexible. I might call Lisp flexible. Try sorting an array of objects by comparing a field from each object in PHP. Now try it in Ruby. But that's not important at the moment, after all, we all had to start somewhere.
However, after having people break into my server through phpBB and Gallery, I replaced those apps with their mod_perl equivalents
This has nothing to do with PHP
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
Re:Don't want to bash PHP.... (Score:2)
After admitting how hard it was to find them, you're going to have to get a dopeslap if you don't tell us what they are.
As a mod_perl hacker about to install Gallery, I'm quite interested.
My God! (Score:2)
Not PostNuke's issue this time, though... (Score:1)
---John Holmes...
Why PHP? (Score:3, Insightful)
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?
Re:Why PHP? (Score:5, Insightful)
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.
Re:Why PHP? (Score:4, Insightful)
See below.
Yes.
Yes.
Yes.
Yes.
Re:Why PHP? (Score:2)
The fact that there are more inexperience people writing PHP code is something that contributes to PHP web apps as a whole, but not really to these recent big exploits particularly.
Un-Exploitable (Score:2)
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 us
Re:Un-Exploitable (Score:2)
"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?"
XML-RPC, actually -- or is that what you meant to type when you wrote "RSS"? It's push vs. pull. Both use XML, but XML-RPC deals with the art of posting to a blog (with a tool like w.bloggar, for example) using the Blogger API, the MT API, and so o
Patching Serendipity (Score:1)
http://www.s9y.org/forums/viewtopic.php?t=2034 [s9y.org]
Save yourself the hassle of doing a complete upgrade by simply downloading the new version an only copying the files from bundled-libs/XML/*
Stupid eval... (Score:2)
Should be forbidden from php.
Ironically, didn't the Windows Logo Certification forbid people from using "system"?
(ouch)
Re:Stupid eval... (Score:2)
XOOPS (Score:2)
Isn't it great... (Score:2, Funny)
Root Me (Score:2)
Zonk and blogging stories (Score:2)
Bragging rights for Perl developers unwarranted (Score:4, Insightful)
Re:Bragging rights for Perl developers unwarranted (Score:2)
If I had modpoints, I would have modded you up.
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, th
Re:How long.. (Score:3, Funny)