February 2019 - dovecot

CVE-2019-3814: Suitable client certificate can be used to login as other user
by Aki Tuomi 05 Feb '19

05 Feb '19

Dear subscribers, we're sharing our latest advisory with you and would like to thank everyone who contributed in finding and solving those vulnerabilities. Feel free to join our bug bounty programs (open-xchange, dovecot, powerdns) at HackerOne. Please find patches for v2.2.36 and v2.3.4 attached, or download new version from https://dovecot.org Yours sincerely, Aki Tuomi Open-Xchange Oy Product: Dovecot Vendor: Open-Xchange Oy Internal reference: DOV-2890 (Bug ID) Vulnerability type: Improper Authentication - Generic (CWE287) Vulnerable versions: 1.1.0 - 2.2.36 and 2.3.0 - 2.3.4 Vulnerable component: authentication Report confidence: Confirmed Solution status: Fixed by Vendor Fixed versions: 2.2.36.1, 2.3.4.1 Vendor notification: 2019-01-16 Solution date: 2019-01-20 Public disclosure: 2019-02-05 Researcher Credits: https://hackerone.com/halfdog CVE reference: CVE-2019-3814 CVSS: 8.2 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N) Vulnerability Details: Normally Dovecot is configured to authenticate imap/pop3/managesieve/submission clients using regular username/password combination. Some installations have also required clients to present a trusted SSL certificate on top of that. It's also possible to configure Dovecot to take the username from the certificate instead of from the user provided authentication. It's also possible to avoid having a password at all, only trusting the SSL certificate. If the provided trusted SSL certificate is missing the username field, Dovecot should be failing the authentication. However, the earlier versions will take the username from the user provided authentication fields (e.g. LOGIN command). If there is no additional password verification, this allows the attacker to login as anyone else in the system. This affects only installations using: auth_ssl_require_client_cert = yes auth_ssl_username_from_cert = yes Attacker must also have access to a valid trusted certificate without the ssl_cert_username_field in it. The default is commonName, which almost certainly exists in all certificates. This could happen for example if ssl_cert_username_field is a field that normally doesn't exist, and attacker has access to a web server's certificate (and key), which is signed with the same CA. Attack can be migitated by having the certificates with proper Extended Key Usage, such as 'TLS Web Server' and 'TLS Web Server Client'. Also, ssl_cert_username_field setting was ignored with external SMTP AUTH, because none of the MTAs (Postfix, Exim) currently send the cert_username field. This may have allowed users with trusted certificate to specify any username in the authentication. This does not apply to Dovecot Submission service. Proof of concept Create a CA certificate for signing, and sign a certificate with missing commoName attribute. With following configuration passdb { driver = static arguments = nopassword } ssl_ca =</path/to/ca.pem auth_ssl_require_client_cert = yes auth_ssl_username_from_cert = yes You are able to log in as any user with this certificate using following commands: openssl s_client -connect server:port -cert /path/to/cert -key /path/to/key a LOGIN anyusername anypassword

1 0

Dovecot 2.3.4.1 released
by Aki Tuomi 05 Feb '19

05 Feb '19

https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz.sig <https://dovecot.org/releases/2.3/dovecot-2.3.2.tar.gz.sig> Binary packages in https://repo.dovecot.org/ * CVE-2019-3814: If imap/pop3/managesieve/submission client has trusted certificate with missing username field (ssl_cert_username_field), under some configurations Dovecot mistakenly trusts the username provided via authentication instead of failing. * ssl_cert_username_field setting was ignored with external SMTP AUTH, because none of the MTAs (Postfix, Exim) currently send the cert_username field. This may have allowed users with trusted certificate to specify any username in the authentication. This bug didn't affect Dovecot's Submission service. --- Aki Tuomi Open-Xchange oy

1 0

acl_groups from LDAP issue
by Jakobus Schürz 04 Feb '19

04 Feb '19

Hi! I have some trouble with userdb, ldap an extrafields for acl_groups. There is a script in python, which fetches the groups and sets the environment-variable ACL_GROUPS to this groups. It works when i log in to imap (thunderbird for example shows my public folders which are protected by acl_groups). But when it try doveadm mailbox list -u user.name the mailboxes are not listed and with -Dv i get "permission denied, no lookup rights". in my dovecot-ldap-userdb.conf.ext is hosts = ldap.server.example dn = cn=service_id,ou=mailserver,ou=system,ou=services,dc=server,dc=example dnpass = protectedpassword12345 tls = yes tls_ca_cert_file = /etc/ssl/certs/ca-certificates.crt tls_require_cert = demand ldap_version = 3 base = ou=users,dc=server,dc=example deref = always scope = subtree user_attrs = =home={ldap:dcMailMessageStore},system_groups_user=%u,allow_all_users=yes,=acl_groups=%{env:ACL_GROUPS} user_filter = (&(objectClass=posixAccount)(uid=%u)(!(sn=NoLogin))(|(memberof=cn=perm-app-mymail_admins,ou=mymail,ou=apps,ou=services,dc=schuerz,dc=at)(memberof=cn=perm-app-mymail_users,ou=mymail,ou=apps,ou=services,dc=schuerz,dc=at))) when i change acl_groups=%{env:ACL_GROUPS} to acl_gropus=mygroup, the doveadm mailbox list command shows my public mailbox So how do i get my acl_groups from the postlogin-script output into userdb-query? Even, when i do on the shell ACL_GROUPS=mygroup doveadm mailbox list -u user.name the ACL_GROUPS Environment is ignored by the doveadm-command... thank you jakob

2 2

Issues with stats-writer
by Remo Mattei 04 Feb '19

04 Feb '19

Here is the full mail coming in: @400000005c57633625970624 starting delivery 12824: msg 1270896 to local ma.org-you(a)mattei.org <mailto:ma.org-you@mattei.org> @400000005c57633625970a0c status: local 1/10 remote 0/60 @400000005c57633711a138c4 delivery 12824: success: lda(you(a)ma.org <mailto:you@ma.org>,)Error:_net_connect_unix(/var/run/dovecot/stats-writer)_failed:_Permission_denied/did_0+0+1/ @400000005c57633711a1447c status: local 0/10 remote 0/60 I am using qmail for some reasons I have the error above. I have tried the following: #service stats { # unix_listener stats-reader { # user = root # group = dovecot # mode = 0660 # } # # unix_listener stats-writer { # user = root # group = dovecot # mode = 0660 # } #} But still no luck still have the same issue. Any tips are welcomed. Remo

1 0

Multi-dbox storage space
by MRob 04 Feb '19

04 Feb '19

Hi, I originally picked mdbox because I had the impression from reading about it on the mailing list that it was more performant and that it would conserve disc space. But lately i found mailboxes have nearly double the storage as reported. I mean, IMAP QUOTA reports around 900MB for one account that has over 2GB when I inspect the mail location of the user using the linux command `du` Another account has around 750MB according to IMAP but using du I find 1.5GB. This is for message files and index files combined. Is this normal? I tried to read the MailboxFormat/dbox wiki page and it does not directly address this topic but it does reference "doveadm purge". Do I need to use "doveadm purge"?

2 2

Crash when using dict quotas with sqlite database
by Marcel Menzel 03 Feb '19

03 Feb '19

Hello, After I configured a SQLite backed dict quota backend, the dict process crashes every time a quota operation is happening. SQLite: 3.26.0 Dovecot: 2.3.4 (0ecbaf23d) Linux: 4.20.4.a-1-hardened #1 SMP PREEMPT Fri Jan 25 01:24:51 CET 2019 x86_64 GNU/Linux (Arch Linux) Filesystem: BTRFS I can't get any debug output from Dovecot, even after setting log_debug = cat:* event:* source:* field:*=* dovecot[6457]: dict(6687): Debug: sqlite: Finished query 'BEGIN TRANSACTION' in 0 msecs dovecot[6457]: dict(6687): Fatal: master: service(dict): child 6687 killed with signal 11 (core dumped) I've attached the output of dovecot -n and the coredump file from systemd-coredump. Kind regards, Marcel Menzel

3 12

Managesieve problem
by Ervin Hegedüs 03 Feb '19

03 Feb '19

Hi, I'ld try to set up the managesieve (for RoundCube) - the sieve is works as well with dovecot (I mean my filters works perfectly). When I would try to connect to managesieve, I got an error, and mail.err contains: dovecot: managesieve(airween(a)mydomain.hu): Error: user airween(a)madomain.hu: Couldn't drop privileges: getgrnam(vmail) failed: Permission denied (in mail_privileged_group setting) Also I got it when I try to connect to port 4190 at localhost (with telnet), and send the generated AUTH string (with sieve-auth-command.pl). Could anybody helps me to explain this message? Thanks, a.

4 6

How to inhibit pop3 server email deletion?
by Davide Marchi 02 Feb '19

02 Feb '19

Hi Friends, for some special needs I would like to inhibit the email deletion from any email client POP3 access. For example prevent the Thunderbird ability to delete server messages older than.. Is this possibile via ACL? Many many thanks! Davide

1 0

Error: User bob@aaa.bbb doesn't have home dir set, disabling duplicate database
by subscription1 02 Feb '19

02 Feb '19

I made a mistake when I moved dovecot to a new server and only specified mail_location instead of mail_home All I have in 10-mail.conf is --------- mail_location = maildir:/home/vmail/mailboxes/%d/%n ------------ All emails for the few accounts I have are in these mailboxes and I can get/see them via my mail client I do, however, get the following error -------------------- imap(bob(a)aaa.bbb): Error: User bob(a)aaa.bbb doesn't have home dir set, disabling duplicate database ------------------- After looking at https://wiki2.dovecot.org/VirtualUsers/Home I tried the following -------------------------------- mail_home = /home/vmail/mailboxes/%d/%n mail_location = maildir:~/mail ------------------------------ Problem with this is that I now can't see any of my emails in the client. Appreciate any help on how to fix this. Thanks

4 8

auth: Error - Request timed out
by Hajo Locke 01 Feb '19

01 Feb '19

Hello List, i use dovecot 2.2.22 and have the same problem described here: https://dovecot.org/pipermail/dovecot/2017-November/110020.html I can confirm that sometimes there is a problem with connection to mysql-db, but sometimes not. Reasons for failing are still under investigation by my mates. My current main problem is, that this fail seems to be a one way ticket for dovecot. Even if mysql is verifyable working again and waiting for connection dovecot stucks furthermore with errors like this: May 29 07:00:49 hostname dovecot: auth: Error: plain(mail(a)example.com,xxx.xxx.xx.xxx,<HGI4FVFt2Oy80j3P>): Request 999.7 timed out after 150 secs, state=1 When restarting dovecot all is immediately working again. Is there a way to tell dovecot to restart auth services or reinitialize mysql-connection after these hard fails? I could insert "idle_kill = 1 mins" into service auth and service auth-worker, but i dont know if this would work. Unfortunately i am not able to reproduce this error and there are always a couple of days between errors. Thanks, Hajo

4 6