[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-3.6.3.html]
Fixed in Postfix 3.6.3, 3.5.13, 3.4.23, 3.3.20:
(problem introduced in Postfix 2.4, released in 2007):
queue file corruption after a Milter (for example, MIMEDefang) made
a request to replace the message body with a copy of that message
body plus additional text (for example, a SpamAssassin report).
The most likely impacts were a) the queue manager reporting a fatal error resulting in email delivery delays, or b) the queue manager reporting the corruption and moving the message to the corrupt queue for damaged messages.
However, a determined adversary could craft an email message that would trigger the bug, and insert into its queue file a content filter destination or a redirect email address. Postfix would then deliver the message headers there, in most cases without delivering the message body. With enough experimentation, an attacker could make Postfix deliver both the message headers and body.
Some details of a successful attack depend on the Milter implementation, and on the Postfix and Milter configuration details; these can be determined remotely through experimentation. Failed experiments may be detected when the queue manager terminates with a fatal error, or when the queue manager moves damaged files to the "corrupt" queue as evidence.
Technical details: when Postfix executes a "replace body" Milter request it will reuse queue file storage that was used by the existing email message body. If the new body is larger, Postfix will append body content to the end of the queue file. The corruption happened when a Milter (for example, MIMEDefang) made a request to replace the body of a message with a new body that contained a copy of the original body plus some new text, and the original body contained a line longer than $line_length_limit bytes (for example, an image encoded in base64 without hard or soft line breaks). In queue files, Postfix stores a long text line as multiple records with up to $line_length_limit bytes each. Unfortunately, Postfix's "replace body" support did not account for the additional queue file space needed to store the second etc. record headers. And thus, the last record(s) of a long text line could overwrite one or more queue file records immediately after the space that was previously occupied by the original message body.
Problem report by Benoit Panizzon.
(problem introduced in Postfix 2.10, released in 2012): The postconf "-x" option could produce incorrect output, because multiple functions were implicitly sharing a buffer for intermediate results. Problem report by raf, root cause analysis by Viktor Dukhovni.
(problem introduced in Postfix 2.11, released in 2013): The check_ccert_access feature worked as expected, but produced a spurious warning when Postfix was built without SASL support. Fix by Brad Barden.
Fix for a compiler warning due to a missing 'const' qualifier when compiling Postfix with OpenSSL 3. Depending on compiler settings this could cause the build to fail.
Fixed in Postfix 3.6:
The known_tcp_ports settings had no effect. It also wasn't fully implemented. Problem report by Peter.
Fix for missing space between a hostname and warning text.
You can find the updated Postfix source code at the mirrors listed at http://www.postfix.org/.