[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:
* postfix-3.1-3.5-tlsa-death-patch (for Postfix 3.1 .. 3.5)
* postfix-3.6-3.7-tlsa-death-patch (for Postfix 3.6 .. 3.7)
* postfix-2.9-3.3-input-limit-patch (for Postfix 2.9 .. 3.3)
* postfix-3.4-3.7-input-limit-patch (for Postfix 3.4 .. 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/.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
