dovecot-2.3.16-11.el9_4.1
エラータID: AXSA:2024-8803:04
Dovecot is an IMAP server for Linux and other UNIX-like systems, written primarily with security in mind. It also contains a small POP3 server, and supports e-mail in either the maildir or mbox format. The SQL drivers and authentication plug-ins are provided as subpackages.
Security Fix(es):
* dovecot: using a large number of address headers may trigger a denial of service (CVE-2024-23184)
* dovecot: very large headers can cause resource exhaustion when parsing message (CVE-2024-23185)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
CVE-2024-23184
Having a large number of address headers (From, To, Cc, Bcc, etc.) becomes excessively CPU intensive. With 100k header lines CPU usage is already 12 seconds, and in a production environment we observed 500k header lines taking 18 minutes to parse. Since this can be triggered by external actors sending emails to a victim, this is a security issue. An external attacker can send specially crafted messages that consume target system resources and cause outage. One can implement restrictions on address headers on MTA component preceding Dovecot. No publicly available exploits are known.
CVE-2024-23185
Very large headers can cause resource exhaustion when parsing message. The message-parser normally reads reasonably sized chunks of the message. However, when it feeds them to message-header-parser, it starts building up "full_value" buffer out of the smaller chunks. The full_value buffer has no size limit, so large headers can cause large memory usage. It doesn't matter whether it's a single long header line, or a single header split into multiple lines. This bug exists in all Dovecot versions. Incoming mails typically have some size limits set by MTA, so even largest possible header size may still fit into Dovecot's vsz_limit. So attackers probably can't DoS a victim user this way. A user could APPEND larger mails though, allowing them to DoS themselves (although maybe cause some memory issues for the backend in general). One can implement restrictions on headers on MTA component preceding Dovecot. No publicly available exploits are known.
Update packages.
Having a large number of address headers (From, To, Cc, Bcc, etc.) becomes excessively CPU intensive. With 100k header lines CPU usage is already 12 seconds, and in a production environment we observed 500k header lines taking 18 minutes to parse. Since this can be triggered by external actors sending emails to a victim, this is a security issue. An external attacker can send specially crafted messages that consume target system resources and cause outage. One can implement restrictions on address headers on MTA component preceding Dovecot. No publicly available exploits are known.
Very large headers can cause resource exhaustion when parsing message. The message-parser normally reads reasonably sized chunks of the message. However, when it feeds them to message-header-parser, it starts building up "full_value" buffer out of the smaller chunks. The full_value buffer has no size limit, so large headers can cause large memory usage. It doesn't matter whether it's a single long header line, or a single header split into multiple lines. This bug exists in all Dovecot versions. Incoming mails typically have some size limits set by MTA, so even largest possible header size may still fit into Dovecot's vsz_limit. So attackers probably can't DoS a victim user this way. A user could APPEND larger mails though, allowing them to DoS themselves (although maybe cause some memory issues for the backend in general). One can implement restrictions on headers on MTA component preceding Dovecot. No publicly available exploits are known.
N/A
SRPMS
- dovecot-2.3.16-11.el9_4.1.src.rpm
MD5: 42bf627e787a7a06644d6090bcd158cb
SHA-256: 51fca5ffd2ee0f2e3ada6da388931eee02b17fce62fbaab3c313a8415d7b334b
Size: 9.15 MB
Asianux Server 9 for x86_64
- dovecot-2.3.16-11.el9_4.1.i686.rpm
MD5: 9a2ea71f81ad1331e1c0afee88d0fbf7
SHA-256: 9afc4937fe4a2be3748778ee4219376d2ae6b48cdb8dc210d5bea074abaef726
Size: 5.24 MB - dovecot-2.3.16-11.el9_4.1.x86_64.rpm
MD5: b71f140513cb4a203054beb46c373611
SHA-256: 83cea2c6d8ca268d062e2665c005a60fe3d856c8bc5cc785cf0aede9f9646e7d
Size: 4.84 MB - dovecot-devel-2.3.16-11.el9_4.1.i686.rpm
MD5: 1190a5fc4bb111f95d6b09d7524abbb7
SHA-256: a60a4b9d3e9ffa047a87c69533e4ce98a388e32fcdeaddcccd586fbb9fc871b8
Size: 595.55 kB - dovecot-devel-2.3.16-11.el9_4.1.x86_64.rpm
MD5: 19ef63a74b50c5915751e7df9b474652
SHA-256: 372418646f55f0c13fcc73b7260f3a9da2777569007dbc232e15eb6cad2b5807
Size: 595.58 kB - dovecot-mysql-2.3.16-11.el9_4.1.x86_64.rpm
MD5: b70b915ca8eae8ab3d457e6593828a54
SHA-256: 7df0e8aac82abee884c3768c94ffd85985106f00b154185bb455072dcfd392e4
Size: 18.23 kB - dovecot-pgsql-2.3.16-11.el9_4.1.x86_64.rpm
MD5: 6499c9ce5ab3c933d4a7d69db4b0c22f
SHA-256: 596871c78608ca4770384aacbc56c8bc39e36963ac49c7c957ab740171e729b0
Size: 22.25 kB - dovecot-pigeonhole-2.3.16-11.el9_4.1.x86_64.rpm
MD5: 1edfc478dadb660c2efd6792ceecae29
SHA-256: 96fb72f32a2f5c98d7436c3317fcd19e935ee84f41f7f329f54bdd4aa4d5bfa1
Size: 385.36 kB