2005-09-04

Bitlbee encrypted storage patch

This patch fixes a security problem with the Bitlbee server. Namely, users' accounts, passwords and contacts are written in plaintext or weakly obfuscated form, that can't stand serious cryptanalysis, on the disk. If the public Bitlbee server gets compromised, much of your personal data can be stolen.

This patch fixes this. It employs CAST5-CBC encryption algorithm and PKCS#5 password-based key derivation with 2^16 iterations to slow down password-guessing attacks. The patch depends on OpenSSL. It also adds more extensive logging to make it possible to track for example repeated logging attempts.

It also fixes a file descriptor leak which could be used for remote DoS attack, and some memory leaks. Namely, in the original Bitlbee, one file descriptor was leaked for each invalid login attempt. If spawned from inetd (the recommended way of running Bitlbee), it is trivial to overflow the system's file descriptor table. And then everything halts.

The file descriptor leak fix made it into the mainstream (latest patches). Memory leaks I didn't report so no official patch is available.

And these bugs I've uncovered only after looking into two functions in the whole source! And I'm not intimately familiar with the code.

Will the "encrypted storage" get merged into the mainstream Bitlbee? I've contacted their authors, and they aren't keen on incorporating it into the mainstream. Guess why - OpenSSL license isn't "free enough" and compatible with GPL. They prefer one of:
  • GNU TLS which, judging from the manual, is inferior to OpenSSL in many ways and lacks features some of which are necessary for the functionality of this patch (among other things, PKCS#5 key derivation).
  • Mozilla NSS which is both an overkill and even less documented than OpenSSL.
After exchanging quite a few messages with the development team on the issues of encryption and file descriptor leaks.. they don't strike me as a serious development team. Criticizing them more (and I do have more to say) would not be fair since they did much work and are keeping the project alive.

My motivation for writing the patch? I'm user of a certain public server and I'm concerned about my data. I have convinced the administrator of that server to apply the encrypted storage patch. He likes the idea.

Bitlbee is also a really great program, although, IMHO, not yet quite ready for public servers. But it's perfectly OK for personal use.

I'm an IRC user and finally I can chat with my friends on IM networks who can't use IRC, without messing around with several different client programs. Thanks to the Bitlbee team.

3 comments:

Senko said...

Just a correction - you said:
"If spawned from inetd, it is trivial to overflow the system's file descriptor table."
Actually the leakage is a problem
when running it as a standalone
daemon. If spawned from inetd, the
server exits upon serving one
client, so the leaked fd would be
reclaimed immediately by the operating system.

zvrba said...

Actually, the problem is exactly as I've described it - when run from inetd.

If run as a single-process daemon, it will overflow per-process fd limit much sooner than the system-wide limit and no harm to the system will come.

When run from inetd, many clients can connect, each having its own, long-lasting process instance of bitlbee. And together they will overflow the system-wide limit of open files.

Wilmer van der Gaast said...

(Wow, it took me two years to find this post..)

This is when it fails to set up an IM-connection? Two years passed now, so I hope this was resolved.

Anyway, about the OpenSSL issue: This isn't something we chose for. I once asked a Gaim developer for permission to use OpenSSL and it was denied. Remember that BitlBee contains a lot of (well, not as much these days as it used to) third-party code which we don't own and can't relicense.

BTW, what do you think of the new .xml file format?