By Jake Edge
September 9, 2009
The WordPress content management system
(CMS) has been in the news lately—for reasons the project and its
users would probably rather not see—as there have been a rash
of attacks
against older versions of WordPress. At least one high-profile blogger,
Robert Scoble, succumbed
to the attack, posting that he no longer felt safe with WordPress.
Various others also piled on, but the problem that was being exploited had
been fixed in early August; the affected sites just hadn't upgraded.
Keeping up with security updates can be time-consuming, especially for
relatively non-technical users who are hosting a CMS site simply to provide
themselves a place to blog. One could easily argue that those kinds of
users would be best served by using one of the free services available for
such things. But, those services tend to have fewer features—often
to encourage upgrading to a subscription-based support plan—leaving
bloggers who want the latest shiny features to host WordPress (or other
similar CMS programs) themselves.
At least for WordPress, many of those shiny features come as plugins to the CMS
engine. When security updates are made, changes required for the plugins
may very well lag behind. Even if the upgrade wouldn't affect the plugins
at all, concerns over that happening led various folks, including Scoble,
to wait a while before upgrading:
I wanted to run my own blog. Mostly so I could use various plugins and play
around. I didn't realize that Wordpress had major holes in it. I figured
that since it was several years old that the nasties had been found and
removed and that it wasn't so brittle. Turns out my assumptions were
wrong. I was also overly scared of upgrades, because of how software
works.
In the comments on Scoble's blog posting (where the above quote comes
from), as well as in a conversation
on his FriendFeed, it is clear that numerous other folks have run into
similar problems with attacks as well as issues with upgrades. WordPress
developer Matt Mullenweg has numerous comments on Scoble's complaints, and
his suggestions are fairly obvious: update immediately when there are
outstanding security patches and, if that's not possible, consider moving
to a managed provider (possibly WordPress.com, the commercial side of
WordPress development).
Mullenweg's advice is good, but it would also seem that the WordPress project
could be doing more to highlight security issues. The
project home page lacks obvious links for security information—though
it currently has a link to Mullenweg's How
to Keep WordPress Secure posting—and searching for "security" on
the site does not bring up any centralized location for that kind of
information. It is probably just an oversight, but even the "Security"
category on the WordPress
blog does not contain the 2.8.3
announcement, which is the release that fixes the problem being
exploited.
For a new, or casual, WordPress user, it would certainly seem possible that
they might miss these security announcements. The WordPress software will
alert the user that there are updates available—and there is an email
list for new release notification—but there numerous ways to add
content to a WordPress blog without logging into the administrative
interface, so the alerts may be missed. It's clear that Mullenweg takes
security seriously based on his comments, but that message may not be
getting out to the WordPress faithful.
The actual bug that is being exploited is a run-of-the-mill privilege
escalation flaw. While the bug itself may be pedestrian, the consequences
are not, as Scoble and others found. Scoble's situation was exacerbated by
not having any backups (!), but the bigger problem is how to get the system
back to a "safe" state after it has been exploited. Depending on how
WordPress was installed, the only safe way to restore a cracked system may
be to reinstall the entire operating system. These kinds of attacks can
leave various back doors behind that stay active even after WordPress
itself has been
upgraded.
The point is not to pick on WordPress, or even CMS programs in general, but
to note a general problem. There is a tension between the fear of
upgrading and the fear of an attack, and many users fear the former much
more than the latter. WordPress has made great strides in simplifying the
upgrade process, but it still has the potential to break
things—especially in plugins that are completely outside of the
project's control. As it turns out, the privilege escalation vulnerability
was related to how certain plugins' administration pages were handled.
Web application security is hard. It is harder still when trying to create
a general purpose web application platform, particularly one that allows
plugins to fairly arbitrarily change its behavior. This is certainly not
the last attack against WordPress or CMS programs that we will see. It is
definitely in the best interest of these projects and their users to pay
close attention to security issues as they arise.
(
Log in to post comments)