LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityAttacks against WordPress installationsThe 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.
Brief items WordPress Blog: How to Keep WordPress SecureHere's an entry on the WordPress Blog on keeping installations secure - a topic WordPress administrators should be especially concerned about at the moment. "Right now there is a worm making its way around old, unpatched versions of WordPress. This particular worm, like many before it, is clever: it registers a user, uses a security bug (fixed earlier in the year) to allow evaluated code to be executed through the permalink structure, makes itself an admin, then uses JavaScript to hide itself when you look at users page, attempts to clean up after itself, then goes quiet so you never notice while it inserts hidden spam and malware into your old posts."
Deep packet inspection engine goes open source (ars technica)Ars technica looks at a free software release of deep packet inspection (DPI) code from ipoque. At least part of the motivation for releasing the code is to allay fears that ipoque's DPI hardware is digging into the actual content, rather than the packet formats and timing, of encrypted traffic, but this release may not succeed in doing that: "The OpenDPI engine, released under the LGPL license, differs from ipoque's commercial scanning engine in its high-priced DPI hardware. The open-source version is much slower and (more importantly) doesn't reveal ipoque's methods for identifying encrypted transmissions. DPI vendors all claim high levels of success at identifying such traffic based on the flow patterns and handshake signatures common to protocols like BitTorrent and Skype, even if they cannot crack the encryption and examine the content of those transmissions."
Security reports Enterprise Linux 5.3 to 5.4 risk reportRed Hat's director of security response, Mark J. Cox, has released another of his risk reports, this one looking at the security updates between RHEL 5.3 and 5.4. He notes that of the nine vulnerabilities of "critical" severity in that time, seven were for Firefox. It is interesting to note that the three NULL pointer vulnerabilities for the kernel were not rated as critical as they were not remotely exploitable. He also points out that three flaws which would have required critical updates, instead required no update—or in one case a low severity update for a denial of service—due to various mitigations (FORTIFY_SOURCE and hardened malloc/free) present in RHEL.
New vulnerabilities cmus: temporary file vulnerability
cyrus-imapd: buffer overflow
devscripts: missing input sanitation
gccxml: temporary file vulnerability
lmbench: temporary file vulnerability
openoffice.org: integer underflow, boundary error
pam: authentication bypass
qt: man-in-the-middle attack
screenie: temporary file vulnerability
silc: several vulnerabilities
tkman: symbolic link vulnerability
xemacs: multiple buffer overflows
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||