WordPress - a hacker's paradise

Saturday, August 13. 2005

PHP applications have a very bad reputation when it comes to security issues. This seems unfair to everyone who actually writtes applications, that are not riddled with security holes, but it is quite understandable when you look how some vendors of prominent PHP applications deal with security problems in an irresponsible way.

One of the really bad examples is WordPress. They have a history of silently fixing vulnerabilities, waiting for ages until they release updated versions or not taking security holes seriously at all. Right at the moment, they know for 25 days about SQL injection vulnerabilities, that are exploitable by registered users. Furthermore they know about a WordPress Remote Code execution exploit in the wild, that was posted to public mailinglists 4 days ago and is widely used to exploit WordPress powered blogs.

It is simply unacceptable and not understandable, that the WordPress developers continue to focus their power on adding new features to WordPress instead of testing their patches and going forward with a security release. In case of the remote code execution exploit they had commited their fix hours before the exploit appeared on full-disclosure. But instead of indepth tests of these patches they are adding new features and close bug tickets. And there is also no warning about this on their download page. The only reference to this vulnerability can be found in their support forum, where they tell their users, that this is only a register_globals issue.

Trustworthy PHPing at it's best. Shame on every vendor that behaves like this.

Posted by Stefan Esser in Security, PHP at 11:36

Comments (8)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 Paul M. Jones wrote (Link) ()

Hi Stefan -- thanks for writing this up and pointing out the issues in WP. I agree that vendors (open or otherwise) should fix prior flaws before adding new features. I'm no security guru myself, but at least when I hear of a serious flaw in my work I drop everything to fix it; I can't understand why others would not do the same. I'm surprised that more PHP security persons aren't paying attention to these issues.

posted on Saturday, August 13. 2005

#2 Paulg ()

Frankly, if you are running register_globals on you have no business doing anything other than print() and echo() using php.

Wordpress, I know has many faults and virtues, but blaming the authors because register_globals is on is like blaming Ford for making fast and dangerous cars, when you kill yourself by flooring the gas pedal and shut your eyes.

Learn how to drive first.

posted on Sunday, August 14. 2005

#2.1 Stefan wrote (Link) ()

This is complete nonsense.

register_globals is turned on on more than half of all PHP servers worldwide. If your application is unable to deal with that it is simply bad.

Not blaming WordPress for their failure to initialise variables is like not blaming someone for his own losses when he gives out a blank cheque.

Stop the false priests that say you can improve web application security with turning off register_globals. You can improve server security with this, but NOT web application security.

So initialise your variables and deregister globals, otherwise your PHP application is not fit for the heterogen PHP world it has to reside in.

-stefan

ps: Geeklog is an application that runs only with register_globals turned on and it is not riddled with security holes...

posted on Sunday, August 14. 2005

#3 Joshua Eichorn wrote (Link) ()

The real fix for all register globals bugs in apps is this.

if (ini_get('register_globals')) {
die('This application will not run with register_globals enabled');
}

posted on Sunday, August 14. 2005

#3.1 Stefan wrote (Link) ()

Are you serious? This will result in people simply removing the 3 lines. Or they will just not use your product, because it is not fit for being used in the mass-market.

posted on Monday, August 15. 2005

#3.1.1 Joshua Eichorn wrote (Link) ()

First if you remove those lines and get hacked i'll laugh at you. Second register_globals is a scourge on the PHP world and I can only hope php6 get rid of it.
Second I write medical software and other internal business apps, they all run on dedicated servers and require the server to be setup correctly. If you host in poorly setup insecure environments you don't deserve to run my apps.

Oh and a great way to make sure that things just fail when registered globals is to put something in the global scope and something in _SESSION with the same name, the magical overwrite that happens is great fun to debug when you do that on accident and don't relieze register_globals is on.

posted on Monday, August 15. 2005

#3.1.1.1 Stefan ()

Yeah, if you prefer to live in a world of dedicated servers, then this is fine for you.

However in the Open Source World, people have to code for a much more hostile and heterogen environment. And hosters actually give a f**k about applications that refuse to work, when register_globals is turned off. The majority of their customers wants it enabled.

If you don't like it, then don't like it.

posted on Monday, August 15. 2005

#4 effisk wrote (Link) ()

Ever heard of DotClear?

lemme help you out... http://www.dotclear.net

posted on Tuesday, August 16. 2005

Add Comment

Name:

Email:

Homepage:

In reply to:

Comment:

Standard emoticons like :-) and ;-) are converted to images.

Remember Information?
Subscribe to this entry

Calendar