dovecot - Dec 2007 - dovecot-auth: returning incorrect maildir for user (user seeing another user's mail)

timo, here is an bizarre bug for you:

i had (foolishly, it turns out) configured dovecot-auth to do ldap 
authentication binding with a prefect userdb (configs at end of 
message). everything worked fine, although with huge numbers of pop 
logins per second we started to see some pileup in the pop3-login 
processes as they were all waiting for ldap responses on the single ldap 
connection. the auth caching was never getting hit (some interaction 
with the prefetch, i assume), but everything worked fine. or so i thought.

we had complaints from a user saying they would occasionally pop another 
user's mail. after much digging, it turned out that if two or more users:
- were logged/logging in at the same time
- had the same password
- got "lucky"
then one of the users would occasionally end up with the other users' 
homedir/maildir. it didn't happen often (maybe once every 500-1000 login 
attempts), but it did happen. (i ended up writing a script that would 
pound the pop3 server with logins and look for the wrong number of 
messages in the inbox. it was not easy to trigger).

i'd already realized that having the auth bind do a search and return 
that to prefetch was a bad idea (since it used a single ldap connection) 
and had already built a new config that used auth binding and userdb 
ldap - when we switched over to that config we were unable to replicate 
the problem again. so, it's not an issue for us right now. i've 
confirmed that the ldap server never returns the wrong homedir, so it 
must have been getting mixed up somehow in dovecot-auth.

but it did seem like something you might want to dig into a bit, as it 
might indicate that something could be amiss somewhere in the auth code. 
that the problem only occured when the users had the same password 
seemed truly bizarre.. sorry i can't provide more details, it was very 
difficult to reproduce (and i was reproducing in a production 
environment and couldn't turn debug up).


the auth section from the poorly behaving dovecot.conf:
auth default {
  mechanisms = plain login
  passdb ldap {
    args = /opt/dovecot-1.0.3/etc/dovecot-ldap.conf
  }
  userdb prefetch {
  }
  user = mail
}

the poorly behaving dovecot-ldap.conf:
hosts = ldap
ldap_version = 3
auth_bind = yes
base = uid=%u,o=imap
user_global_uid = 8
user_global_gid = 8
dn = uid=imap at dovecot,o=imap
dnpass = ******
pass_filter = (&(proto=%s)(remoteip=%r)(localip=%l)(mech=%m)(pid=%p))
pass_attrs = 
home=userdb_home,quota=userdb_quota,nologin=nologin,reason=reason,user=user

note: the ldap server does some custom processing based on the filter - 
the filter was the easiest way to get them passed to it. (in case that 
looks a little wierd :)

On Thu, 2007-12-20 at 13:57 -0500, Brendan wrote:
> i had (foolishly, it turns out) configured dovecot-auth to do ldap 
> authentication binding with a prefect userdb (configs at end of 
> message). everything worked fine, although with huge numbers of pop 
> logins per second we started to see some pileup in the pop3-login 
> processes as they were all waiting for ldap responses on the single ldap 
> connection. 
Maybe I should change this so it uses two connections. If you're not
using auth_bind_userdn setting it would do 3 lookups (passdb/dn, bind,
userdb).
> base = uid=%u,o=imap
..
> pass_filter = (&(proto=%s)(remoteip=%r)(localip=%l)(mech=%m)(pid=%p))
Authentication cache uses %variables in pass_filter as the cache key.
The reason why it wasn't working was because %s,%r,%l,%m,%p combination
rarely matched twice. But once in a while it could have matched, causing
Dovecot to return cached values for a wrong user because pass_filter
didn't contain %u.

The problem only happened with users with same password, because the
password was still checked against cached one. Normally someone should
have probably wondered why their login was failing, except Dovecot does
this automatic "if password doesn't match cached one, but last login
was
successful, ignore cache and do the passdb lookup".

So the solution is to include base's contents in auth cache key as well.
Fixed: http://hg.dovecot.org/dovecot-1.0/rev/2cedab21cd6d

Hmm. I suppose this could be considered a security hole.. Time for
v1.0.10 then.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20071220/154e73e1/attachment-0002.bin>