[Secure-testing-team] Bug#729063: dovecot: CVE-2013-6171

[Moritz Muehlenhoff]

Package: dovecot
Severity: important
Tags: security

Quoting from the 2.2.7 announcement:
http://www.dovecot.org/list/dovecot-news/2013-November/000264.html

| Some usage of passdb checkpassword could have been exploitable by
| local users. You may need to modify your setup to keep it working.
| See http://wiki2.dovecot.org/AuthDatabase/CheckPassword#Security

Quoting from http://wiki2.dovecot.org/AuthDatabase/CheckPassword#Security:

| The standard checkpassword design is incompatible with Dovecot's security model. If 
| the system has local users and the checkpassword script setuid()s into a local user, 
| the user is able to ptrace into the communication and change the authentication results. 
| This is of course undesirable, so v2.2.7+ will just refuse to run in such environments 
| by default. The possibilities to solve this are:
|    If possible, change the checkpassword to return userdb_uid and userdb_gid extra fields 
| instead of using setuid() and setgid(). This also improves the performance.
|    If you can't change the script, you can make Dovecot's checkpassword-reply binary 
| setuid or setgid (e.g. chgrp dovecot /usr/local/libexec/dovecot/checkpassword-reply; 
| chmod g+s /usr/local/libexec/dovecot/checkpassword-reply)
|
| If you don't have any untrusted local users and you just don't care about this check, you 
| can set INSECURE_SETUID=1 environment e.g. with a wrapper checkpassword script. 

I'm not sure if that needs to be backported to stable given? How popular is the Checkpassword
auth framework?

Cheers,
        Moritz