ejabberd fails at ssl
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ejabberd (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: ejabberd
Hi,
From what I can tell, it looks like there are two significant security problems in the patch that added SSL support to ejabberd's ldap module (added in 2.0.0-7; see debian bug #477918) --
1) The validity of peer SSL certificates is not verified: the call to ssl:connect in the patch explicitly sets the value for "verify" to 0:
ssl:connect(Host, State#eldap.port, [{verify,0}|Opts]).
In the Erlang SSL library[1] this setting translates to "do not verify peer." An attacker who is able to perform a man-in-the-middle attack would thus be able to spoof the LDAP server and intercept any passwords sent over the wire. For sites using LDAP with simple authentication, this would expose the credentials of all users who authenticate to the ejabberd server.
(Please note that, simply enabling peer certificate validation will probably break a number of ejabberd installations, as there is currently no way (that I have found) of specifying a custom CA certificate...)
2) The same bit of code uses a very low-entropy source of data to seed the SSL library:
{_,_,X} = erlang:now(),
ssl:seed(
This seeds the SSL library with a constant string and the current number of microseconds, which is a very weak source of entropy. I am uncertain of the practical effect of this seed, but the Erlang SSL documentation[1] contains a number of notes like this:
It is strongly advised to seed the random generator after the ssl application has been started, and before any connections are established. Although the port program interfacing to the OpenSSL libraries does a "random" seeding of its own in order to make everything work properly, that seeding is by no means random for the world since it has a constant value which is known to everyone reading the source code of the seeding.
On Debian/Ubuntu systems, it seems wiser to read a few bytes from /dev/urandom and use that as the seed...
Please take a few minutes to review these issues, and let mw know what you think.
Thanks!
-sq
Changed in ejabberd: | |
status: | New → Confirmed |
Changed in ejabberd (Ubuntu): | |
status: | Confirmed → Fix Released |
Since version 2.0.5-1 (in karmic) the ldaps patch got dropped because it didn't apply anymore. Upstream is working on integrating ldaps support into mainline so the extra patch won't be needed anymore - but it might take a bit until a release is made that ships this.
So for the time being this bugreport can either be considered invalid for karmic, or as a wishlist to have it re-added.