" (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." Please file a stablereq for 3.6.3 when ready.
Ah, I'd seen the start of this on their ML, but it wasn't yet clear if it was a vulnerability when I last checked a few days ago. Thank you for noticing this!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=839fc438c640d30ee15a14be9bac99bd498394ad commit 839fc438c640d30ee15a14be9bac99bd498394ad Author: Eray Aslan <eras@gentoo.org> AuthorDate: 2021-11-19 11:12:44 +0000 Commit: Eray Aslan <eras@gentoo.org> CommitDate: 2021-11-19 11:12:44 +0000 mail-mta/postfix: cleanup Bug: https://bugs.gentoo.org/822753 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Eray Aslan <eras@gentoo.org> mail-mta/postfix/Manifest | 2 - mail-mta/postfix/postfix-3.6.1-r1.ebuild | 289 ------------------------------ mail-mta/postfix/postfix-3.6.2-r3.ebuild | 286 ------------------------------ mail-mta/postfix/postfix-3.6.2-r4.ebuild | 290 ------------------------------- 4 files changed, 867 deletions(-)
Thanks Eray!
