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."

Why PHP?

[mcc]

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?

Re:i was hacked yesterday

[DrSkwid]

sounds like you are a bit paranoid thewrre larry me old beauty

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:Don't want to bash PHP....

[Saeed al-Sahaf]

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.

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....

[Anonymous Coward]

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.

Seriously, at least once a week.

Re:Why PHP?

[eddy the lip]

...or is it just that there are more inexperienced people writing PHP code out there...

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?

[Saeed al-Sahaf]

...Is there something about PHP that's making these things likely as opposed to some other language...

See below.

...or is it just that there are more inexperienced people writing PHP code out there...

Yes.

...or is it just that PHP site engines are getting installed by more security-inexperienced people...

Yes.

...or are the PHP exploits getting publicized more...

Yes.

...or am I just noticing them more...

Yes.

Re:Makes me happy

[Sepodati]

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...

Re:Wouldn't This Be Called an XML Injection Attack

[Anonymous Coward]

I prefer a hot beef injection

Re:Don't want to bash PHP....

[Tassach]

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

I'd say while it isn't exactly a PHP vulnerability it is an inherent PHP design flaw, which renders PHP dangerous (if not useless) for it's intended user community.

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.

Bragging rights for Perl developers unwarranted

[timbrown]

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.