1.5.1.3 – remote code execution 0-DDAAYY exploit

A patch has been created and should be committed soon. Actually, the idea is to completely kill all register_globals type exploits.

According to “experts” on the subject this is a PHP issue and not just related to WordPress and has been known for a while:

“The register_globals is evil. You shouldn’t have it turned on anyway. Turn it off. Now.”

This is also according to PHP and security expert, Chris Shiflett.

To turn it off, add the following line to your .htaccess file in your WordPress root directory on your server, if your host server supports the use of php_flags:

php_flag register_globals off

And now it is fixed.

Claiming that “register_globals is evil” is nothing but FUD. Not register_globals per se is evil, but lazy programmers that rely on it – or write flawed “deregistration layers”.

Contrary to self-proclaimed “security experts” claiming otherwise, there is a lot of PHP products that run very well with register_globals on or off, without having to resort to finger pointing at a language feature.

Do you “experts” also consider echo evil because it can be used to greatly faciliate XSS attacks by not filtering output? Or mysql_query() – because without it, SQL injection would not be possible? Your logic is seriously flawed.

It is good that you have used quotes around “experts”.

Because according to experts this is an issue with poorly programmed PHP applications. A problem caused by lazy programmers that do not initialize their variables.

When you write C code you also have security problems if you do not initialize your variables. This is for sure not a PHP issue.

And as a sidenote: Chris Shiflett is not a security expert. I invite you to look into his very own software projects, that you can download from his website. In his wwwforum you will find nearly every possible security hole that one can construct within a PHP application.

Btw: turning of register_globals in your .htaccess will not work at all on non apache webservers.

Btw2: the WordPress team knows about other security holes in WordPress 1.5.1.3 for some time now, but they consider them not important enough to fix them.

That’s interesting, because at no point have the WP developers ever shown this type of characteristic. I’d like to see even one known exploit that the devs refuse to fix.

Ask photomatt.

For various reasons, the core WordPress developers (that is, Ryan and Matt) do not discuss WordPress exploits until a patch is available, and a release plan is in place.

The vitriol about unpatched vulnerabilities is mis-placed. Matt and Ryan have an obligation to make sure that the problems they fix do not cause more trouble. We experienced this with 1.5.1.2, which was released to fix a problem, and ended up introducing additional problems.

And as I said, it involves more than just patching. The patches need to be sufficiently tested. The upgrade process needs to be supported by the volunteers here. Simply releasing a new version, and saying “here you go!” would do more harm than good.

I’m not thrilled about the existence of security vulnerabilities; but it’s a fact of life that they’ll always be present. WordPress is an increasingly complex piece of software, and although Matt and Ryan make an effort to be security conscious in their coding, they are after all human beings. We all make mistakes; we all have bad days; we all overlook some things.

You can help, rather than complain.

Every single reader here is invited to participate in WordPress’ development. If you notice problems, please log them at trac.www.ads-software.com. If you discover a severe vulnerability, email [email protected]. The Open Source mantra is “With many eyes, all bugs are small.” By working together, we can squash bugs and make sure that WordPress is as secure as it can be.

Code has been checked in to safely initialize all variables that could “leak” through on systems with register_globals on. Like you said, setting the phpflag isn’t possible on all systems. A universal solution is the goal.

By all means, look at the new code and utilize the Trac bug reporting system to contribute improvements.

Will that line of code in the.htaccess file resolve the issue? I am thankful that you are aware of this issue and will quickly resolve it.

Let me provide you with some motivation – a nightmere result of this vulnerability hits a novice – me! I got hit within the last 24 hours through this exploit and an IRC bot got onto my server. My webhost suspended my account (thinking it was my maliciousness – later pointed me to this post and realized it wasn’t me) and I just about lost it! I have a big demo in less than two hours, so I had to explain that I’m no sysadmin or programmer – just know enough html and css to get by using wordpress. Thankfully, he appeared to resolve the issue and reinstated my account. Whew! Website back up!

Thanks for looking into and resolving this serious issue.

The line should resolve the issue on apache servers. A better solution is to tell your host that register_globals should be off in php.ini, and it will greatly improve their security.

What other precautions might I try? Should I change webhost account passwords along with wordpress passwords? Are these vulnerable as a result?

It already appears that I might be getting a bit more comment spam than before, but that could be my imagination.

for those in which the .htaccess solution doesn’t work, you might be able to do this, if your host allows you to have custom php.ini files.

https://forums.site5.com/showthread.php?t=961&highlight=register_globals

Anyone know if DreamHost has globals turned on by default?

By default, register_globals is turned on with DH.

To turn it off, add php_flag register_globals off to your .htaccess file as Lorelle mentioned.