Hi all,
we are releasing a CVE patch release 2.3.21.1.
https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot
Kind regards, Aki Tuomi Open-Xchange oy
- CVE-2024-23184: A large number of address headers in email resulted in excessive CPU usage.
- CVE-2024-23185: Abnormally large email headers are now truncated or discarded, with a limit of 10MB on a single header and 50MB for all the headers of all the parts of an email.
- oauth2: Dovecot would send client_id and client_secret as POST parameters to introspection server. These need to be optionally in Basic auth instead as required by OIDC specification.
- oauth2: JWT key type check was too strict.
- oauth2: JWT token audience was not validated against client_id as required by OIDC specification.
- oauth2: XOAUTH2 and OAUTHBEARER mechanisms were not giving out protocol specific error message on all errors. This broke OIDC discovery.
- oauth2: JWT aud validation was not performed if aud was missing from token, but was configured on Dovecot.
On 15/08/24 00:07, Marc via dovecot via dovecot wrote:
El9 packages are in GhettoForge: http://ghettoforge.org/
2.3.21.1 is being built now and will hopefully be released in a couple of hours.
Peter
Hi Aki,
we are releasing a CVE patch release 2.3.21.1.
Your message to the oss-security list [0] says both 2.2 and 2.3 versions are vulnerable to CVE-2024-23184. Using the following test message as reproducer
From: foo@example.net
To: bar1@example.net
, bar2@example.net
[…]
, bar$n@example.net
Bcc: baz1@example.net
[…]
Bcc: baz$n@example.net
Date: $(LC_TIME=C.UTF-8 date -R)
Subject: boom
Message-Id: $(cat /proc/sys/kernel/random/uuid)@example.net
boomI could reproduce the issue back to 2.3.10 but not with earlier
versions. I used doveadm fetch imap.envelope all to measure the
(non-cached) IMAP ENVELOPE command.
For n=100k, it takes ~20s with 2.3.19 vs. ~0.5s with early 2.3.x and 2.2.x. For n=500k, I measured ~2s with early 2.3.x and 2.2.x, so for these versions it doesn't look like parsing is O(n²) in the number of addresses.
I didn't try to bisect to pinpoint the exact commit, but AFAICT the main problem you described
| each header line's address is added to the end of a linked list. This | is done by walking the whole linked list, which becomes more inefficient | the more addresses there are.
was introduced in 2.3.10 by https://github.com/dovecot/core/commit/469fcd3bdd7df40bb8f4d131121f3bfbceade... .
Is my reproducer/analysis incorrect, or are versions before 2.3.10 immune to CVE-2024-23184? (AFAICT they are affected by CVE-2024-23185; only talking about -23184 here.)
Thanks,
Guilhem.
On 14/08/24 23:25, Aki Tuomi via dovecot wrote:
Tests failing when attempting to build for both EL8 and 9:
test-failures.c:152: Assert failed: internal_line_match(line, long_log_prefix, TEXT128) test-failures.c:152: Assert failed: internal_line_match(line, long_log_prefix, TEXT128) test-failures.c:152: Assert failed: internal_line_match(line, long_log_prefix, TEXT128)
...this test did not fail in 2.3.21
Peter
participants (5)
-
Aki Tuomi
-
Guilhem Moulin
-
Marc
-
Peter
-
Timo Sirainen