WordPress Wins Pwnie Award for Mass 0wnage (For Many Many Security Vulnerabilities)
WordPress wins the dubious distinction of Mass 0wnage Pwnie Award for an unbelievable number of WordPress vulnerabilities, over 140 as of today.
It seems like hardly a week goes by without a new vulnerability in WordPress or one of its many plugins. Many of them are actively being exploited to own popular WordPress blogs and use them to serve spam or client-side exploits to unsuspecting visitors. The popularity of WordPress combined with the abysmal security practices of WordPress plugin developers places the entire Internet at risk and is worthy of a nomination.
WordPress is known for quick releases but also for quicker updates after a major release which almost always consists of some disclosed and some undisclosed security vulnerabilities. WordPress disproves the open source software security theory based on "many eyeballs" which assumes that given enough people who review the code, almost any weakness of the software will be found and fixed. WordPress is open source and yet it is infested with security vulnerabilities.
The "security by obscurity" approach to security adopted by WordPress developers isn't really working. Will Matt & his merry team finally wake up and do a security audit?
Filed under Computer Security, Headline News, Pro Blogging, Web, Web 2.0, WordPress, WordPress Plugin | 
| 
RSS 2.0 |
Trackback this Article
| 
Email this Article
You may also like to read |
August 10th, 2008 at 6:25 pm
Hi, do you have any reference for this news (WordPress winning)?
I think the mass ownage pwnie award went to WMF. Was WordPress even a nominee?
August 11th, 2008 at 8:08 pm
“Mass 0wnage went to Wordpress for many many vulnerabilities.”
- Source
August 12th, 2008 at 12:18 am
@Mark see my comment above for the source (pointed to by Matt Cutts in his tweet).
August 21st, 2008 at 4:19 pm
Security audit? No. Never. Any sane person following wp-hackers development close enough would NOT even believe such thing will happen. The only thing ever related is just some repeated murmuring of it and angry complaints more than 2 years ago. Nothing more.
August 21st, 2008 at 9:23 pm
Well said. I wonder why? Isn’t it time WordPress developers realized their inadequacy in providing robust security to WordPress?
August 25th, 2008 at 4:57 pm
Most vulnerabilities are found internally by the WordPress community, especially Alexander Concha. WordPress.com has been audited at the request of some of the VIPs hosted there. WP has been audited by some security groups looking for publicity. It has been audited by students as part of their studies. It has been audited quite a lot. There is nothing obscure about our security, that’s a big reason why you actually know what our security problems are.
Many CVEs are for plugins, are duplicates, or are invalid. Of the CVEs issued for 2008, only a few are valid and applicable to core WordPress. We’ve certainly had too many security problems, but nowhere near as many as the CVE list implies.
WP’s popularity means a lot of CVEs and debate about our security are generated, even for practices that other blogging and CMS platforms continue to use. Others store md5 hashed or even plain text passwords while we use salted and stretched password hashes that defy rainbow tables. We use a well-researched, thoroughly audited cookie protocol. We sign cookies with a key stored in the DB and another defined in PHP so that a compromised DB or a misconfigured http server won’t compromise cookie signing. We don’t deliver auth cookies outside of the admin. We’re eliminating use of mt_rand() in favor of something more random. We’re ahead of the game in these areas. Of course, when one of the thousands of WP plugins is compromised and sites get owned, our name is mud regardless. That’s why we introduced automatic plugin upgrades, and are planning to do both automatic and manual security audits of plugins hosted at /extend/plugins/.
August 26th, 2008 at 5:25 am
> There is nothing obscure about our security, that’s a big reason why you actually know what our security problems are.
I actually can point out many times when an update was released for security reasons but without disclosing the actual vulnerability, I had blogged about it in the past too.
> when one of the thousands of WP plugins is compromised and sites get owned, our name is mud regardless
One solution could be to run the plugins in a sandbox. More on it later.
> That’s why we introduced automatic plugin upgrades, and are planning to do both automatic and manual security audits of plugins hosted at /extend/plugins/
Last I checked /extend/plugins is only for GOL’ed plugins. What about plugins which are not GPL or aren’t free? Why not extend the security audit facility to any plugin developer?
However I think in the long run using a sandbox model will improve security.
I understand your concern about plugins. Such problems would have been very easy to address in language like Java which allows for security restrictions in external code through security manager and other means. Unfortunately in PHP it is harder to implement.
However you still cannot shift the focus solely to plugin developers. WordPress (core) over the years had too many serious security vulnerabilities and while they somewhat decreased with the maturity of the product, it is still alarming.
You mention several formal security audits on WordPress, if I understand you correctly. Can you please point me to any available documents which provides more details like scope of the audit and their verdict? I still see some issues when I delve into the code.
BTW: The biggest architectural issue I see with WP plugins framework is that a plugin author can easily introduce trojans (or worse) in sites using them.