If you don’t know by now, WordPress 2.8.4 has hit the public and it addresses a mild but hugely annoying issue. There was no advanced warning regarding the vulnerability but it was quickly patched in the core of WordPress for the next release. Unfortunately, word quickly spread and in fact, even my site WPTavern.com was affected by the problem as I received an email letting me know what my new password was even though I didn’t request one. Here are the details regarding the annoyance:
a specially crafted URL could be requested that would allow an attacker to bypass a security check to verify a user requested a password reset. As a result, the first account without a key in the database (usually the admin account) would have its password reset and a new password would be emailed to the account owner. This doesn’t allow remote access, but it is very annoying.
Thus WordPress 2.8.4. However, there are certain ways in which to respectfully report security vulnerabilities. An article on the vulnerability published by Programmerfish.com in my opinion did more harm than good. The article discusses the vulnerability, explains how to put it in practice, then goes on to show some examples of the vulnerability in action which the author performed on sites they didn’t own. The author tries to justify his/her actions by stating that it was just a proof-of-concept. The author has taken plenty of heat from folks in the comments which I believe to be appropriate.
The Correct Way:
If you discover a security problem with WordPress, this is the correct way to go about it. If you believe you’ve found a security problem in a release of WordPress please send mail to security at the WordPress.org domain and we’ll do our best to address it as soon as possible.
It is standard practice to notify the vendor (the WordPress developers, in this case) of a security problem before publicizing so a fix can be prepared and public damage due to the vulnerability minimized.
If you would like to see this method put into practice, check out the report time line from CoreLabs, a research and development company that discovered the privileges unchecked in admin.php problem which lead to the release of WordPress 2.8.1. They notified the WordPress team on June 6th of the problem. By communicating back and forth, the issue was resolved by July 8th. A day after, the new versions of WordPress and WordPress MU were released to the public to minimize damage of the exploit. In this situation, everyone wins.
I am wondering why he would even care about proof of concept?
We all know security issues exist, thats the same with any program written in the PHP language. I probably would have said “so whats your point? people hack blogs and websites?” my response to that would be simply….”w’ll DUUH!” hehe. I just think there’s got to be more to the story then that.
Who knows. I would have performed the vulnerability on sites I own and showed that rather than using other peoples sites as an example.
great way to start a wednesday morning!
Heh, did you read this while sipping on coffee?
I couldn’t agree more.
By all means, report vulnerabilities. But you don’t have to report them to everyone ‘out there’, where so many rotters could have a great time with it, causing trouble to the people that use WordPress.
Right. Openly known vulnerabilities are always much worse than ones that are reported behind the scenes. It’s a shame this person decided to cause trouble instead of prevent it.
A very big “Amen” to this one. Though I wasn’t affected by this bug, I was very worried that I could be. WordPress developers are VERy good about addressing security flaws so not reporting this one to the developers before spreading the bug itself around was outright irresponsible.
Did it get a patch out quicker? Maybe. But it definitely did more damage this way.
I would’ve like to see the Dev Blog link to a the trac where we could see the tickets they fixed in 2.8.4. I went over there but couldn’t find a list of the fixes included in the release.
Based on what I can see, I may be wrong but the only changes to core were to the wp-login.php file to address the security issue.
Here you go http://core.trac.wordpress.org.....ches%2F2.8 that will list all the changes that occurred in 2.8.4
List of the changes in a somewhat nicer format:
http://core.trac.wordpress.org....._rev=11767
Also, why does WordPress continue to include the version number in the header? That continues to be used by bots intending to attack older (and insecure) versions of WordPress. I know there are plugins to fix this, but why doesn’t that get removed from the core? Is there any reason for having it there?
I dunno, I can ask and get back with you on that one.
I would appreciate that, Jeff. Thanks.
Jeff, did you find anything out on this?
I did ask, but Otto here in the comments pretty much sums up what was said.
But my point is, if there is no known reason to have this, why is it there? Especially when there is a chance that it could be used to hack sites.
Bots don’t give a crap about the version number.
If you’re trying to exploit as many sites as possible, then it’s cheaper, quicker, and easier to simply spam your exploit out there as fast as you can, regardless of the version number. If the exploit fails, who cares?
Think of it like this. Your way:
– HTTP GET on the site, parse it, check the version number. If it is vulnerable, do yet another HTTP request to perform the exploit. If not vulnerable, go to next site.
My way:
– HTTP request to perform the exploit. If failure, go to next site.
Which is quicker? Which makes more sense for a bot author to do?
Otto, for what purpose is the version number in the header of a WordPress frontend page?
Well yes, we all know that security by obscurity is best practice, don’t we?
I would have loved to run a” proof-of-concept” on his blog and see how he likes it.
For me it was a different case where one of my subscriber kept getting the pasword reset notifications, there were like about 10 in for the same person before I got to know of the bug.
In all that I received a change of password for admin only once and since am set up to have to verify the request I just ignored the email 🙂
the thing is, most people that find bugs and exploits would rather see them published than contacting the software developers, its the world we live in.
I suppose I should consider myself lucky. Every one of my clients runs WordPress – most have multiple installations/domains. I have yet to get a single ticket about this vulnerability.
It’s too bad the vulnerability was released the way it was, but at least the WP crew were able to release a fix quickly.