With all the noise around "the bug" behind us a little bit, I guess it's now time to stop being so vague about the "account hijacking" bugs we've fixed. I didn't want to give all details right away, to give public server maintainers some time to upgrade. Only a few maintainers picked up the fixes, and I don't want to wait any longer.

A few weeks ago, while redoing the "set" command a little bit, I discovered something I didn't really like. When you connect to a BitlBee server and immediately use "set password" to change your password, even though you haven't used identify/register yet to get yourself authenticated, BitlBee just said "Password changed successfully". Although it didn't actually create an account file yet, one could then use "save" to then get this done. While the "register" command checks if an account exists before writing to disk, the "save" command doesn't (and shouldn't). Quickly, 1.2.2 was released. Why did this happen? It turns out that this problem was with us for some time already. Previously, the "password" setting was disabled until the user registers/identifies. This was changed in this bzr revision.

Unfortunately, this wasn't the only problem. It turned out the "register" command was also not working very well. Although it checked for the existence of an account before creating it, it did leave a password set in the BitlBee state structure. This allowed for a very similar exploit, where after failing to register an account, one could use the "save" command to get his account saved anyway. This problem was introduced somewhere in the migration to the storage abstraction layer.

All these issues should be gone now, and I'm working on a blackbox testing system that will continuously check for bugs like this (and also test other various pieces of BitlBee functionality) to (hopefully) prevent nasty bugs in the future.

Also, I see security advisories about this issue are often wrong about the "hijacking" part, so I have to repeat this once more: Although this exploit indeed allows one to create an account on a BitlBee, bypassing all safety checks (including AuthMode=Registered), it is not possible to use this bug to gain access to other people's accounts! When someone performs this attack, he will simply get the victim's account deleted. IM passwords in BitlBee configuration files are encrypted using the user's password. There is absolutely no way to figure out these passwords without cracking the person's BitlBee password.

Unfortunately 1.2.2 did not fix all possible account hijacking loopholes. Another very similar flaw was found by Tero Marttila. In the migration to the user configuration storage abstraction layer, a few safeguards that prevent overwriting existing accounts disappeared. Over the week I went over all the related code to make sure that everything's done in a sane, safe and consistent way.

It looks like not all public servers are up to date yet. If you own one, please update it as soon as you can to save your users any inconvenience from losing their account.

I just released BitlBee 1.2.2, and I advice public server maintainers to upgrade their BitlBee daemons as soon as possible, since this release fixes a security bug that was probably there for a long time already.

It's not a serious bug, it doesn't allow anyone to compromise your server. It does allow people to hijack accounts, though. Not with gaining access to the IM accounts or settings of the existing user, it only allows people to recreate an existing account.

Again, your machine (and for the users, your privacy) is not in danger. But please upgrade anyway to make sure this gap is closed.

Update (2008-08-30 14:23 (UTC)): Some testing showed that the bug does not exist in any 1.0.x release or older. BitlBee 1.1dev/1.2 were the first releases with this vulnerability.

Both testing.bitlbee.org and im.bitlbee.org are now running a bzr snapshot version of BitlBee that does MSN Passport authentication the old way. This should resolve the login problems. A 1.2.2 release will probably come soon, I want this to be stable on the public servers for a few days first.

Update (2008-08-02 11:04 (UTC)): Actually, I rolled back in vain, just hours after I did this, Microsoft fixed their bug. 1.2.x users should be fine again.

This is known for a few days already, but a post on the webpage still can't hurt, I think. Apparently BitlBee has issues logging into the MSN Messenger network these days, if your password contains non-alphanumeric characters or even capitals. It affects some people, others can still log in. The problem is discussed in the bug tracker.

This seems to affect other clients too. There's one easy fix, which is reverting to the old non-SOAP authentication method. I'm trying to avoid doing that since that code was messy. If I can't find any better solution soon, I'll probably do that and roll it out to the public servers.

If you absolutely need MSN to work, you can change your password or switch back to BitlBeee 1.1.1dev for a while.

Today (on my watch this day is going to end in five minutes already, actually..) BitlBee reached the age of six years! Since it's been a while since the 1.2 release and since there are fixes for a lot of bugs in bzr by now, I decided to make this a release.

This code is running on testing for a while already, with not too many changes, and it's extremely stable. For the first time, we're actually running BitlBee in daemon mode for all SSL connections. It's serving thirty users from just one process, running without any issues for weeks in a row. This is quite an improvement over the unstable unreliable program the Bee once used to be!

Of course I'm not saying that the program is perfect now, please keep sending those bug reports. :-) But first, enjoy BitlBee 1.2.1!