[An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.11.4.html]
This release addresses five low-impact problems that need to be addressed as they can reduce safety margins.
In addition to updated releases for the supported Postfix versions 3.8-3.11, patches will also be available at the Postfix source mirror sites for the out-of-support Postfix versions 2.9-3.7:
These patches come with the same PGP, GPG1 and GPG2 signatures as Postfix release tarballs and patches.
Fixed in Postfix 3.8-3.11:
Bug 1 (defect introduced: Postfix 3.1, date 20150607): null pointer read and heap data overread in the Postfix SMTP client's smtp_dns_reply_filter. Problem reported by TristanInSec, found with ASAN. Also reported by other people. Reproduction and real-world impact researched by Wietse.
Root cause for bug 1:
A missing 'break' statement after the code that converts a TLSA record to string.
Reproduction for bug 1:
The problem happens when smtp_dns_reply_filter is configured (this is disabled by default); the Postfix SMTP client is configured to use opportunistic or mandatory DANE authentication (this is disabled by default); the destination domain publishes a TLSA record that is empty or shorter than 20 bytes; and the OS is configured to use a resolver that passes such a TLSA record. For example, a zero-length TLSA record is blocked by BIND, Google DNS, OpenDNS, and by configurations that use systemd-resolved (the default on many LINUX systems); it is passed by Cloudflare, Quad9 DNS, and unbound, as long as these resolvers are used without systemd-resolved.
Impact statement for bug 1:
SMTP client termination with a null pointer read crash when the TLSA record length is zero; or an SMTP client data overread (or rarely, SMTP client termination with a read segfault crash) when 0 < record length < 20 bytes. The overread content is not disclosed.
Performance impact of bugs 1 and 2:
The impact of SMTP client crashes (voluntary or not) is easily overstated. That said, crashes must be eliminated regardless of their impact.
On systems that deliver fewer than one message per minute, an SMTP client crash can result in a delay of up to one minute for email delivery to other destination domains.
On systems with a larger traffic volume, the impact of an SMTP client crash on deliveries to other destination domains is minor because Postfix reuses SMTP client processes and replaces a failed process within seconds (self-healing); the practical impact is believed to be no worse than that of an uncooperative receiver that tarpits SMTP connections from Postfix to one or more destination domains under their control (by replying within Postfix SMTP client read time limits which are several minutes by default).
Bug 2 (defect introduced: Postfix 3.6, date: 20200710): panic (assertion failure and voluntary crash) while parsing a TLSA reply with length 3. Found during code maintenance. See below for root cause, reproduction, and impact.
Root cause for bug 2:
An incorrect test 'length < 3' instead of 'length <= 3' causes a safety check to fail when a TLSA parser attempts to create zero-length storage for a non-existent TLSA certificate association data field.
Reproduction for bug 2:
The problem happens when the Postfix SMTP client is configured to use opportunistic or mandatory DANE authentication (this is disabled by default); a destination domain publishes a TLSA record with a length of three bytes; and the OS is configured to use a resolver that passes such a TLSA record. For example, a length-three TLSA record is blocked by BIND, and by configurations that use systemd-resolved (the default on many LINUX systems). It is passed by many other resolvers.
Bug 2 enables an attack that is more potent than bug 1.
An attack with a length-three TLSA reply does not depend on smtp_dns_reply_filter configuration.
An attack with a length-three TLSA reply propagates through more resolvers than an attack with a length-zero TLSA reply.
Impact statement for bug 2:
SMTP client voluntary termination (crash) after an assertion failure. This is a fail-safe mechanism.
See also above for "Performance impact of bugs 1 and 2".
Bug 3 (Problem introduced: Postfix 2.9, date: 20110205) Robustness: the Postfix SMTP server will no longer receive (and discard) an unlimited amount of text while receiving a long SMTP command line. Problem reported by Michael Wollner (Ibonok). Under high load conditions, the amount of text was already limited by a 10-second deadline to receive an SMTP command.
Bug 4 Robustness: with the above change the Postfix SMTP client will no longer receive (and discard) an unlimited amount of text while receiving a long SMTP response line.
Bug 5 (Problem introduced: Postfix 3.4, date: 20180825) Robustness: do not receive (and discard) unlimited amounts of data with BDAT commands. Problem found during code maintenance. File: smtpd/smtpd.c.
Impact statement for bugs 3, 4, 5:
Postfix should not receive and discard unlimited amounts of input in SMTP command lines or BDAT chunks, but fixing that will not fundamentally change the situation.
By design, any SMTP client can force a server to receive (and discard) an unlimited amount of text.
For example, an attacker can repeatedly send messages that are a little under the server's message size limit and abort each transaction a before reaching the message end. When sending a message with the "DATA" command, an attacker would disconnect instead of sending <CR><LF>.<CR><LF>; and when sending a message with the "BDAT" command, an attacker would send "RSET" instead of "BDAT LAST".
To mitigate such abuse, Postfix can rate-limit the number of message transactions from the same IP address or address range (see smtpd_client_message_rate_limit and *prefix_length parameters). Such a defense is ineffective when faced with a distributed attack (botnet); for that, postscreen combined with an IP reputation service (DNSBL) may be more effective.
You can find the updated Postfix source code at the mirrors listed at https://www.postfix.org/.