Although all WordPress users should upgrade right away, we’ve also added a security rule to our servers to try and protect our customers who haven’t yet upgraded. Other people may also find the security rule useful if they use mod_security on Apache Web servers. The rest of this post contains more technical details.

So what’s the security problem with WordPress 2.5? Well, if your blog allows strangers to register, the vulnerability allows evildoers to create a new unprivileged username like “admin0″, then use the cookie from that username to login as the privileged username “admin”.

This works because WordPress creates a login cookie with a value like this for “admin0″:

admin0|1209331453|2a771ff005c67b2aaa0a872aaa213f39

The first part is the username, the second part is the cookie’s expiration time, and the third part is an MD5 hash of the concatenated username, expiration, and some secret text.

The trouble is that this cookie is also valid:

admin|01209331453|2a771ff005c67b2aaa0a872aaa213f39

We simply moved the “0″ from the end of “admin” to the beginning of the expiration. Although this changes the username, it doesn’t change the MD5 hash! That’s because the text that the hash is based on doesn’t contain a separator such as a pipe character, as it should. In either case, it’s just hashing “admin01209331453″ (plus the same secret text), and the identical hash is valid for both the privileged and unprivileged users. A nasty bug indeed.

You don’t necessarily need to use “0″ on the end of the username, either; other digits can be made to work. They increase the expiration time of the cookie, but that doesn’t make it invalid.

So this vulnerability allows people to create a WordPress username ending in one or more digits, then use the cookie from that username to login as another username without the digits on the end.

Here’s where mod_security can be useful. It’s a great defensive tool that we’ve been using more and more to protect our customers from this kind of attack. If it’s possible to identify something that’s different about an “evil” page request (compared to a “good” page request), you can probably block the evil request using mod_security.

In this case, one thing immediately stands out: a “good” request always has a 10 digit expiration time in the cookie, but a “bad” request always has 11 or more digits. If we can block WordPress cookies that contain 11 or more digit expirations, that should block the evil request.

This rule for mod_security 1.x does the trick:

SecFilterSelective HTTP_Cookie "wordpress_[a-f0-9]{32}=[^\|]+\|[0-9]{11,}\|[a-f0-9]{32}"

And here’s the same rule for mod_security 2.x:

SecRule REQUEST_HEADERS:Cookie "wordpress_[a-f0-9]{32}=[^\|]+\|[0-9]{11,}\|[a-f0-9]{32}"

This looks for a cookie value containing 11 or more digits between the pipe symbols. This rule successfully blocks a test attack we created, and does not appear to give false positives (we’ve had it in place on servers that have served several million pages over the last few hours, with no matches beyond our tests).

Just so it’s clear, our customers don’t need to use these rules, because they’re already on all our servers — but we hope they’re useful to someone else.

Of course, if you know of any other attack vectors, please post a comment so we can improve the rules.

However, thread view has a potential downside: it you have several active threads going with several messages each, new messages can sometimes appear on the second page of the incoming mail screens, instead of the first page.

That’s not a problem if you’re expecting it. However, since we introduced the new Webmail system, we’ve had several complaints from customers who accidentally clicked “Switch to Thread View” without realizing what it does, then thought some of their incoming mail was missing because they aren’t used to looking for new mail on other pages. Since thread view is “remembered” even after you logout and login again, this caused some people a great deal of heartache.

From our logs, we’ve found that very few people actually use thread view. Because it seems to cause frequent problems and few people use it, we’ve made it an optional feature instead of being always enabled.

If (like most people) you don’t use thread view, you don’t need to do anything. If do you want to use thread view, it’s still available: just click “Preferences”, then click “Display Preferences”, then change “Show ‘Thread View’ Link” to “Yes”.

Anyway, it turns out that Apple convinced some of you to take leave of your financial senses, too, and you’ve been asking us how to set up your iPhone to read your e-mail. So we’ve spent many hours voiding the warranty on our phone, getting it to the point where we could extract detailed screen shots showing exactly how to set up iPhone mail. If you have an iPhone, give it a try! Our servers handle iPhone e-mail connections just fine — and the connections are fully encrypted by default, making sure your e-mail and passwords stay secure as you roam the world on strangers’ WiFi networks.

The most obvious is that the interface is terribly ugly (the Mailman developers are working on a big improvement to this, thankfully; just so it’s clear, we didn’t create the program, and we’re as horrified by the circa-1996 appearance as everyone else). Another problem with the program, though, is the option for “monthly password reminders”. This is a design flaw that’s being removed from Mailman, and although most of the lists on our servers don’t use password reminders, customers who do should probably turn them off now in preparation for that change.

So what’s the issue? The main problem is that Mailman sends people’s personal passwords over the Internet via plain text e-mail, which is about as secure as sending them around the world on a postcard. One of the most basic password security rules for users is “memorize a password instead of writing it down anywhere”, and Mailman completely breaks that rule. And one of the most basic rules for secure software designers is “store passwords only in encrypted form so that even the program author and system administrator can’t tell what they originally were, so that if hackers break into the system they can’t tell either”. Mailman breaks this rule, too — it has to, in order to be able to send the monthly password reminders. The authors of Mailman attempted to solve this problem by adding a note to the subscription page saying “do not use a valuable password”, but that goes against human nature; some people will inevitably enter the same password they use for online banking, etc.

There’s another problem with password reminders, too, which is that if you have more than one Mailman list, the password reminders are sent from the e-mail address of a seemingly random one of those lists, even if the recipient isn’t subscribed to that particular list. Not a security problem, but certainly annoying.

Anyway, bottom line: monthly password reminders are a bad idea and don’t work properly anyway. The good news is that the Mailman developers have completely removed password reminders and plaintext passwords from the next version of Mailman, which we’ll be using when it becomes available. If your list uses monthly password reminders, they’re going to go away, hopefully soon. (In fact, we consider the password reminders such a source of problems that if the new version of Mailman is substantially delayed, we may end up preemptively disabling them for all lists on our servers.)

This actually won’t affect most of our customers, because the Mailman setup wizard in our control panel hasn’t turned on the password reminders option for new lists for a long time now. However, a few older lists had it enabled by default, and it’s still possible for customers to manually enable it by clicking one of the obscure options in the Mailman administrative interface.

If your list uses password reminders, we recommend turning them off now:

1. Login to the administration page for your list
2. Scroll down to the “Send monthly password reminders?” setting and change it to “No”
3. Scroll to the bottom of the page and click “Submit Your Changes”.

Doing this makes the list more secure for your subscribers, and also makes sure you’re not surprised when password reminders stop by themselves.

If you have trouble disabling the reminders, just contact us and we’ll be glad to do it for you.

Since we have many servers, each one gets a name to let us keep track of them. They’re actually called “farnsworth.tigertech.net” and so forth, but we usually just mention the first part.

Web hosting accounts are assigned to a particular server: if we say “the farnsworth server will be rebooted”, that means that only customers with accounts on that particular server are affected, but other customers won’t notice anything at all.

All well and good — but how can you tell which server your account is on? The answer is that when you login to our control panel, the server name is now shown at the top of the screen in small print. You’ll see something like “Web hosting account with free domain name renewal (on server ‘farnsworth’)”. (If you have more than one domain name, the different domain names may be on different servers.)

By the way, as a bonus for reading this far — the first customer to post a comment saying where our server names come from gets a free month of Web hosting!

However, in the long term it’s better to use mailboxes on our servers (referred to as “POP mailboxes” on our setup screens, although they can also be accessed by IMAP or Webmail). In fact, one of the biggest advantages of having your own Web site and domain name is that you own it and all of its e-mail addresses. From our experience this is much better than being at the whim of a company that’s almost impossible to contact if you have trouble.

In fact, even if you decide to stop using us for your e-mail and Web hosting you can take your e-mail addresses with you when you leave. Another advantage is that it gives us complete control over your mail instead of making us the “middleman”. If you have any trouble, we can track your messages in our logs and diagnose the problem. If you forward mail to another company, it’s a bit like sending it into a black hole and hoping it comes out the other end. Unfortunately if something does go wrong there’s no guarantee that we would be able to contact someone at the other end who is willing to help.

So if you haven’t done so already, try creating a mailbox! It really is quick and easy and you can even use our Webmail system to check your messages. (We also have a new Web mail system in the pipeline based on Squirrelmail — advanced users can also install their own copy of Squirrelmail right now. Keep checking our blog for updates!)

For instance, we often have customers who cannot send and receive mail using the mail programs on their personal computers. After checking the mail servers and port numbers, everything seems to be set up correctly, but the mail program refuses to work. In these situations we often ask customers to restart their computer. Surprisingly they often tell us that everything works again.

So why does restarting the computer help? The problem is normally related to the antivirus software on the PC, especially software that intercepts incoming and outgoing mail connections (it’s common with Norton and Symantec antivirus products). The virus scanner somehow “hangs” and needs to be restarted — but virus scanner manufacturers aren’t going out of their way to make it easy to restart the scanners (they invisibly run in the background on your PC). The simplest fix is restarting your whole computer.