v1.0.8 and v1.0.9 were a bit bad releases. Hopefully one day I've
managed to have written a proper test suite which can be run before
doing any releases..
* Security hole with LDAP+auth cache: If base setting contained
%variables they weren't included in auth cache key, which broke
caching. This could have caused different users with same passwords
to log in as each other.
- LDAP: Fixed potential infinite looping when connection to LDAP
server was lost and there were queued requests.
- mbox: More changes to fix problems caused by v1.0.8 and v1.0.9.
- Maildir: Fixed a UIDLIST_IS_LOCKED() assert-crash in some conditions
(caused by changes in v1.0.9)
- If protocols=none, don't require imap executables to exist
Somehow I doubt there are any Dovecot setups left that unknowingly have
this problem, but it still counts as a security hole. The possibility to
cause this problem exists in Dovecot v1.0.rc11 and later.
If you use:
1. passdb ldap with settings:
- auth_bind = yes
- auth_bind_userdn = no
- base containing %variables required for unique user identification,
e.g. base = dc=%d,dc=org
- pass_filter not containing all %variables required for unique user
- pass_attrs returning user-specific settings, such as user's home
2. userdb prefetch
3. auth_cache_size non-zero (0 is default)
If two users with the same password and same pass_filter variables log
in within auth_cache_ttl seconds (1h by default), the second user may
get logged in with the first user's cached pass_attrs. For example if
pass_attrs contained the user's home/mail directory, this would mean
that the second user will be accessing the first user's mails.
You most likely would have noticed this already by wondering why logins
keep failing, unless pass_filter used also some %variables that most of
the time uniquely identifies the user. For example %r (remote IP
address) or %n (username without domain).
You can fix this by upgrading to v1.0.10 (to be released soon), or using
this patch: http://hg.dovecot.org/dovecot-1.0/raw-rev/2cedab21cd6d