- dovecot - dovecot.org

CVE-2022-30550: Privilege escalation possible in dovecot when similar master and non-master passdbs are used
by Aki Tuomi 10 Jul '22

10 Jul '22

Affected product: Dovecot IMAP Server Internal reference: DOV-5320 Vulnerability type: Improper Access Control (CWE-284) Vulnerable version: 2.2 Vulnerable component: submission Report confidence: Confirmed Solution status: Fixed in main Researcher credits: Julian Brook (julezman) Vendor notification: 2022-05-06 CVE reference: CVE-2022-30550 CVSS: 6.8 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) Vulnerability Details: When two passdb configuration entries exist in Dovecot configuration, which have the same driver and args settings, the incorrect username_filter and mechanism settings can be applied to passdb definitions. These incorrectly applied settings can lead to an unintended security configuration and can permit privilege escalation with certain configurations involving master user authentication. Dovecot documentation does not advise against the use of passdb definitions which have the same driver and args settings. One such configuration would be where an administrator wishes to use the same pam configuration or passwd file for both normal and master users but use the username_filter setting to restrict which of the users is able to be a master user. Risk: If same passwd file or PAM is used for both normal and master users, it is possible for attacker to become master user. Workaround: Always authenticate master users from different source than regular users, e.g. using a separate passwd file. Alternatively, you can use global ACLs to ensure that only legimate master users have priviledged access. Fix: This has been fixed in main branch. See https://github.com/dovecot/core/compare/7bad6a24%5E..a1022072.patch

5 5

User authentication / activity log
by Karl Denninger 07 Jul '22

07 Jul '22

I'm on 2.3.19.1 (9b53102964) running on FreeBSD, if it matters. I have a set of maintenance "things" that I want to have happen if someone does not authenticate against Dovecot (to check mail) after some period of time. I was running the Z-Push exchange server, which (as its in PHP) made sticking an "you were here" flag in the user's filesystem easy, which of course means checking it is easy since the modification time on the file is sufficient. I was looking for something similar that I could use with Dovecot and my first thought was the cache or index files, but as it turns out local delivery (I'm running Postfix) updates those, so they're not left alone if no client is connected. I also don't see anything appropriate in the syslog that dovecot dumps into there I can scan for on a sign-in. My auth mechanism is "straight" login, no LDAP or similar, and I use pam as the mechanism. I don't see anything in the auth.log file or dovecot's logs. My authentication section for dovecot is pretty-basic: auth_mechanisms = login disable_plaintext_auth = yes passdb { args = session=yes dovecot driver = pam } protocols = imap Does Dovecot maintain something that I can reasonably find in the filesystem for this? A perusal of the documentation doesn't appear to show anything directly pertinent -- but I may have missed it. It appears that the event export capacity might be able to do this but I'm confused on how to set it up; what would be very useful is if, for each user, the log point could be different (e.g. in their home directory) and if it allowed overwriting (thus becoming an activity flag, basically.) Thanks in advance! -- Karl Denninger karl(a)denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/

2 2

Case sensitivity and unicode normalisation on ZFS for Dovecot Maildir
by Jørn Åne de Jong 06 Jul '22

06 Jul '22

I'm wondering about some filesystem considerations when using Dovecot. I've read https://wiki.dovecot.org/FileSystems, but that basically talks about low-level details. My question is not about that. I use the following mail_location: maildir:~/maildir:LAYOUT=fs:INBOX=~/maildir/INBOX:UTF-8 In this setup, because I use LAYOUT=fs and UTF-8, the IMAP names are identical to the directory names. I noticed that the INBOX name is case-insensitive, but all other names are case-sensitive. I wonder if it's possible to have consistent behaviour here. Now since I use ZFS, I have the ability to make the filesystem case insensitive and to normalise unicode codepoints. Is that something that would be useful when running a Dovecot server, or would that be a bad idea?

2 1

Trivial Pigeonhole patch: allow X-Original-From header for address tests
by Rob Foehl 04 Jul '22

04 Jul '22

Motivated by more DMARC silliness, naturally. -Rob

2 2

Découvrez notre offre GitLab Hébergée et Infogérée par Bearstech
by news＠bearstech.com 28 Jun '22

28 Jun '22

Découvrez notre offre GitLab Hébergée et Infogérée par Bearstech GitLab <http://phplist.bearstech.com/lists/lt.php?tid=Tza50Ap4TD2gj9FrGpMNfI8Q2GhbL…> s'est imposé au fil des ans comme une des solutions de gestion de code la plus complète et performante, supporté par une communauté Open Source dynamique, et des dizaines de millions d'utilisateurs. Nous hébergeons et infogèrons des Gitlab <http://phplist.bearstech.com/lists/lt.php?tid=Tza50Ap4TD2gj9FrGpMNfI8Q2GhbL…> depuis 10 ans pour nos clients. Ayant développé une expertise autant en exploitation qu'en conseil pour mettre en place et améliorer des workflows de déploiement complexes, nous avons décidé de proposer une offre simple et capable d'évoluer en fonction du dimensionnement de vos projets. Cette offre GitLab <http://phplist.bearstech.com/lists/lt.php?tid=Tza50Ap4TD2gj9FrGpMNfI8Q2GhbL…> est hébergée sur notre propre infrastructure, localisée en France. Nous offrons un niveau de support et une qualité de service irréprochable, avec une disponibilité garantie de 99.9%. Nous assurons un service d'astreinte 24h/7j/365. Les serveurs étant infogérés par Bearstech, la sécurité et la fiabilité de votre forge répondent ainsi aux plus hauts standards du métier. Au lieu d'un coût par utilisateur, nous vous proposons un prix mensuel correspondant aux ressources matérielles et à vos usages, votre budget est donc maitrisé et prévisible, le coût par utilisateur étant rapidement moins cher que sur l'offre Gitlab.com. Votre garantie, un support personnalisé, avec des experts capables de vous apporter des retours d'expérience précieux et améliorer continuellement votre démarche DevOps. Découvrez notre offre Gitlab Hébergée et infogérée par Bearstech <http://phplist.bearstech.com/lists/lt.php?tid=Tza50Ap4TD2gj9FrGpMNfI8Q2GhbL…>

1 0

Doveadm http requests - payload size
by Tony Hartmann - WebBoty 22 Jun '22

22 Jun '22

Hello Team, We are running dovecot version (2.3.7.2 (3c910f64b)) on ubuntu 20.04. Using the doveadm tool via http api we can create emails and move them accordingly to the draft folder by sending http requests via cURL from another server. We can even attach files. However once we create a http API request bigger than 1MB in size we get the “PAYLOAD TO LARGE” response from dovecot. Going through the config I see no option to increase the allowed payload size for doveadm http api requests. However in the source code itself I see that there is a default limit/size of: #define HTTP_REQUEST_DEFAULT_MAX_PAYLOAD_SIZE (1 * 1024 * 1024) Further I found out that the default is only used if no limit is provided: === if (limits != NULL) { hdr_limits = limits->header; max_payload_size = limits->max_payload_size; } else { i_zero(&hdr_limits); max_payload_size = 0; } /* substitute default limits */ if (parser->max_target_length == 0) parser->max_target_length = HTTP_REQUEST_DEFAULT_MAX_TARGET_LENGTH; if (hdr_limits.max_size == 0) hdr_limits.max_size = HTTP_REQUEST_DEFAULT_MAX_HEADER_SIZE; if (hdr_limits.max_field_size == 0) hdr_limits.max_field_size = HTTP_REQUEST_DEFAULT_MAX_HEADER_FIELD_SIZE; if (hdr_limits.max_fields == 0) hdr_limits.max_fields = HTTP_REQUEST_DEFAULT_MAX_HEADER_FIELDS; if (max_payload_size == 0) max_payload_size = HTTP_REQUEST_DEFAULT_MAX_PAYLOAD_SIZE; if ((flags & HTTP_REQUEST_PARSE_FLAG_STRICT) != 0) msg_flags |= HTTP_MESSAGE_PARSE_FLAG_STRICT; http_message_parser_init(&parser->parser, input, &hdr_limits, max_payload_size, msg_flags); return parser; The question arises … how can we change / set the allowed payload size for the doveadm http api, so we can store bigger emails and attachments? Can we store the desired allowed payload size in an env file somewhere or are there any options to take control of the allowed payload size without changing the source code? Thanks in advance Tony

1 0

running alternate dovecot instances on the same server
by Chris Hoogendyk 22 Jun '22

22 Jun '22

I'm posting to the list, but not on the list. I presume that means a reply-all to get to me as well as the list? We have two servers (dovecot --version: 2.2.22 (fe789d2)) that handle email for two different departments. We are transitioning mail service to the University central IT. They need to move accounts in an automated fashion and therefore need a master password to our dovecot servers. However, we are running with LDAP authentication, and I understand that a master password is not possible in that configuration. Would it be possible to run an alternate dovecot process that would use local account authentication, have a master password, and use an alternate port for connecting? Ideally it would only read accounts without changing anything, and would not interfere with the operation of the other dovecot process. I'm hoping that I could copy the configuration files, make these changes, and then launch it manually without any startup scripts in /etc/inetd.conf. Oh, by the way, we are running Ubuntu 16.04 LTS and have contracts with Ubuntu Advantage for ongoing patch support. The dovecot version is from the distribution, installed with aptitude. -- --------------- Chris Hoogendyk - O__ ---- Systems Administrator, Retired c/ /'_ --- Biology & Geosciences Departments (*) \(*) -- 315 Morrill Science Center III ~~~~~~~~~~ - University of Massachusetts, Amherst <hoogendyk(a)bio.umass.edu> --------------- Erdös 4

3 7

dovecot and openssl3
by A. Schulze 21 Jun '22

21 Jun '22

Hello, I tried to build dovecot-2.3.19.1 with openssl-3.0.2 "make test" failed. Good, the test-suite found a problem! I found similar reports and patches: - https://sources.debian.org/src/dovecot/1%3A2.3.19%2Bdfsg1-1/debian/patches/… - https://bugzilla.redhat.com/show_bug.cgi?id=1962035 - https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/1945763 - https://launchpadlibrarian.net/569387479/dovecot.debdiff The patch looks easy and at least 'make test' pass again. Could the dovecot developer have a look at the patch and say something about the roadmap to support openssl3? Thanks Andreas

1 0

Malformed XLIST replies
by Bogdan Szczurek 21 Jun '22

21 Jun '22

Hi! Some (considerable) time ago, I, as one of the Mailspring (https://getmailspring.com/) users, had a problem with setting up IMAP email account hosted on home.pl. I was able to narrow down the problem to how the Mailspring handles server response regarding folder list. The problem is twofold: a) how the response is handled by Mailspring's IMAP libraries, b) how the server itself responds. As to the first part of the problem I submitted relevant bug reports (https://github.com/MailCore/mailcore2/issues/1908 and https://github.com/dinhvh/libetpan/issues/403) and but the second part appears to belong here, since home.pl uses Dovecot as their IMAP server. Now about the problem. When XLIST is used to get the list of the folders, I get, for example: 3 XLIST "" "*" * XLIST (\HasNoChildren \) "." "Archive" * XLIST (\HasNoChildren \) "." "Courses" * XLIST (\HasNoChildren \Draft) "." "DRAFTS" * XLIST (\HasNoChildren \Inbox) "." "INBOX" * XLIST (\HasChildren \) "." "PhD" * XLIST (\HasNoChildren \) "." "PhD.Advisor" * XLIST (\HasNoChildren \) "." "PhD.Archive" * XLIST (\HasNoChildren \) "." "PhD.Articles" * XLIST (\HasNoChildren \) "." "PhD.Conferences" * XLIST (\HasNoChildren \) "." "PhD.Journals" * XLIST (\HasNoChildren \) "." "PhD.Thesis" 3 OK Completed Compare this with the LIST output: 4 LIST "" "*" * LIST (\HasNoChildren) "." "Archive" * LIST (\HasNoChildren) "." "Courses" * LIST (\HasNoChildren \Drafts) "." "DRAFTS" * LIST (\HasNoChildren) "." "INBOX" * LIST (\HasChildren) "." "PhD" * LIST (\HasNoChildren) "." "PhD.Advisor" * LIST (\HasNoChildren) "." "PhD.Archive" * LIST (\HasNoChildren) "." "PhD.Articles" * LIST (\HasNoChildren) "." "PhD.Conferences" * LIST (\HasNoChildren) "." "PhD.Journals" * LIST (\HasNoChildren) "." "PhD.Thesis" 4 OK Completed Notice, how in the XLIST example, every item has an additional “empty” flag (“\”). This part causes libetpan to fail. While ignoring the problem as a library's problem would be perfectly understandable, I think it should be also considered if something shouldn't be done on Dovecot's end. Granted, XLIST has been long depreceated, however it still is implemented and it should be implemented properly. Perhaps I'm mistaken, but I failed to find any mention of a thing like “empty flag”. It might not be prohibited, but it strikes me as something bizarre. I am unable to get the information about the Dovecot version used by home.pl, but I suspect this problem may still be present up to the newest version. Also, if someone is willing to take a closer look at the problem, I can provide you with an email account for testing purposes. Best regards! Bogdan

2 1

v2.3.19.1 released
by Aki Tuomi 21 Jun '22

21 Jun '22

Hi everyone! Due to a severe bug in doveadm deduplicate, we are releasing patch release 2.3.19.1. Please find it at locations below: https://dovecot.org/releases/2.3/dovecot-2.3.19.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.19.1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot Aki Tuomi Open-Xchange oy --- - doveadm deduplicate: Non-duplicate mails were deleted. v2.3.19 regression. - auth: Crash would occur when iterating multiple backends. Fixes: Panic: file userdb-blocking.c: line 125 (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL)

3 7