I’ve found BlogSecurity’s WordPress Scanner to be invaluable for me; I’ve recently brought a bunch of installs up to current, but I hadn’t considered the vulnerabilities in XSS attacks on templates. But now that I know that those have holes, too, I can patch them up.
Go give WordPress Scanner a shot: all you’ll need to do to let it run is to put
<!-- wpscanner --> somewhere in your template. I’d suggest putting it in the Header, where any page that WordPress Scanner comes across would have access to the statement. That way, all pages can be scanned for vulnerabilities. Just be sure to remove it after the scan is over so some black hat can’t use it against you! 😉
It would be awesome if WordPress would include a post-upgrade scanner into the mix, checking your theme for possible holes. Upgrading WP only fixes the core files—any template you’ve used other than the default isn’t going to get fixed, and it could have a hole.
Back when I saw Wincent Colaiuta’s strident slamming of the security holes in WordPress 2.2, I commented, “I think Colaiuta overstates his case here, but the point is taken: this should have been pushed out faster.” I brought it up with Stephen at lunch yesterday, and we talked about some of the issues at play here. I think that they are:
- Self-hosted WordPress installations not making a big enough deal to the end-user that their install is out-of-date.
- A lack of a regimented test case suite on multiple platforms [Apache, IIS, etc.] to root out any bugs in release candidates.
- The delay between discovery and patch release.
WordPress founder Matt Mullenweg has angrily responded. I’m a bit disappointed in Matt, because he takes every opportunity to take digs at Colaiuta’s platform of choice, rather than calmly and rationally dissecting the argument that Colaiuta made. This is perhaps understandable, as WordPress is the foundation of Matt’s career, but for him personally and WordPress in general, I wish that he’d responded with more grace.
- # The SQL problem in 2.2 requires both registration to be enabled (off by default) and the blog to be upgraded to 2.2. It is a serious problem but I’ve heard of fewer than 5 exploits from the flaw. Even if you assume there are 100 blogs for every one we heard about, that’s still an incredibly small percentage of the millions of WordPresses out there, especially considering, as Wincent points out, the problem has been in the public for a while now.
- Getting people to upgrade web software is hard. We work as best we can with hosting companies, but a consideration is that it’s best to roll several security fixes into one release. It’s not responsible to do a release if we know of another problem, so sometimes there is a lag between an initial report and a final release, not to mention the testing required of a product used as much as WP.
Those are the salient points here. The first is pretty important: the flaw was only vulnerable if you go away from WordPress’s defaults. The chances are that the users who are too lazy or unaware of the risks to keep their software up-to-date aren’t going to have changed many of the defaults. I run a community of Webloggers using self-hosted WordPress installs, and I can tell you that very, very few of them—maybe 5%—have ever done anything different than the default options.
The second point is important as well, although there’s not enough apparent testing to me—as a power user who sorta half-monitors wp-hackers, albeit with less frequency right now because I’m covered up with work—to be sure that this is fully the issue here. I don’t have a problem with a quick #.#.X release for a bug such as this, because good tools to keep your installations up-to-date exist. When 2.2.1 was released the other night, I patched 30+ installations in under a half-hour across as many domains on my server, all by hand. [The “40 minutes” comment is how long the 2.2.1 release had been out in the wild.] When I finished upgrading all my RMFO-Blogs users to 2.2.1—the re-architecture took quite some time, and had bitten me in the ass by running 2.0.2 [!] for months and getting my server 0wn3d—today, I went and upgraded about 30 users whom I’d already gotten up to 2.2 in about 15 minutes—again, by hand. I’m working on a shell script to automate this and make it much, much faster for me.
The big thing that’s come to mind for me lately is that WP needs to set an annoyance factor for release updates. At present, WP includes your version at the bottom of every page in the admin—which is good. That’s not enough, though. If you’re running an outdated installation, WP ought to bitch at you every opportunity it gets. How? There ought to be a banner at the top of every single WordPress admin page, using that lovely yellow-fade-to-blue status notice, that annoys the crap out of the user by letting them know that their installation is outdated. If I had that for my RMFO-Blogs users, I can guarantee that this would have them banging on my doorstep to do an upgrade for them. Another possibility is that any WP installation that’s out-of-date could, using WP-Cron, send a daily email to the administrator email address, advising them that their installation is out-of-date, and providing them URLs on where to download the files to upgrade and providing help pages for upgrading.
Security is a serious issue. It should be treated soberly. Matt’s angry, unprofessional response—choosing to sling a lot of mud at Movable Type—simply muddies the conversation. I had hoped for better from him. I do hope that we’ll see better in the future.
As Joe Gregorio notes, WordPress was supposed to support Atom 1.0 starting with the 1.6 milestone [which, as I recall, never happened and became 2.0]. Mark Pilgrim is frustrated, too. So am I, but this should be a surprise to exactly no one.
But being one to work within the system … there’s the new Ideas forum, and well, there’s a topic to support Atom 1.0 support in the next release. I’ve already chimed in. Go rate it up. If we all rate it up, perhaps it will become a priority. [It should be, anyway; WP is shipping to a deprecated version of a specification, something really outside the main WP ethos.]
I complained nine months ago about the lack of Atom 1.0 support in WordPress. It’s still a bit stunning to me that, a few releases later, WP still doesn’t have that support. But today, Sam Ruby pointed to Benjamin Smedburg’s plugin that generates Atom 1.0 output for WordPress. Huzzah!
I’ve gotta say that I find ticket 2972 to be wonderfully right-headed:
Currently, the most recent page (in any of the archives — dated, categorized) is page number 0. When clicking on Next Page, the url shows it being paged=1, thus page number 1. Going back even further, the page numbers increase.
However, when new posts are added, all the content in the pages shift with it.
In my opinion, it would be better if the oldest posts would be on page 1. This way, if new posts are added, consequently new pages are added. AND the content of the pages stay the same.
It’s all about future-proofing, and that’s a very, very good thing.
So I decide to do some investigation. I have a variety of WordPress installations at various revision levels across the server I administer. [Bad, I know!] Anyhow, my results were as follows:
v2.0 RSS2 feed shows up as returning 304. v2.0.1 RSS2 feed shows up as returning 304. WordPress.com RSS2 feed shows up as returning 304. v2.0.2 RSS2 feed does not return a 304.
I have checked the /rss/, /comment/, and /atom/ feeds for IJSM.org and they also show no 304 headers returned.
The comments feed for the 2.0.1 install I have returns a 304 as it should.
Seems that the issue definitely showed up in the 2.0.1—>2.0.2 transition.
I don’t know if this is related to the security fixes of 2.0.1—>2.0.2; if so, I’m okay with it. I’ll take the bandwidth hit on my box over the probability of my box being 0WN3d. That said, this is still an issue.
I really and truly mean that. I’ll take the bandwidth penalty! … for now. Eagle-eyed readers will suspect that I’ve future-posted this entry; indeed, I have. It was written Friday night to give the WP guys 24 hours’ notice. I figure that I owe them that.
Kudos to WordPress for doing well in Joe Clark’s assessment of WordPress against the Authoring Tool Accessibillity Guidelines. The main complaint seems to be against the WordPress toolbar in the Write/Edit page in the admin, which I would argue needs further development. After all, there are cases where you want i elements instead of ems: for example, any proper title that you choose to italicize really isn’t something that you’re emphasizing; you’re just using italic type to alert the reader to the presence of a proper title.
The easiest way to summarize Clark’s finding is this: WordPress’s core commitment to producing standards-compliant markup makes it generally very accessible. The WP development crew should read Clark’s assessment, feel a sense of pride, and heed the minor suggestions and constructive criticisms provided.