Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 822753

Summary: <mail-mta/postfix-3.6.3: queue file corruption
Product: Gentoo Security Reporter: John Helmert III <ajak>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Status: IN_PROGRESS ---    
Severity: minor CC: eras, hydrapolic, sam, williamh
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard: B4 [glsa?]
Package list:
Runtime testing required: ---
Bug Depends on: 822981    
Bug Blocks:    

Description John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2021-11-09 23:09:48 UTC

(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.
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-11-09 23:13:45 UTC
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!
Comment 2 Larry the Git Cow gentoo-dev 2021-11-19 11:13:03 UTC
The bug has been referenced in the following commit(s):

commit 839fc438c640d30ee15a14be9bac99bd498394ad
Author:     Eray Aslan <>
AuthorDate: 2021-11-19 11:12:44 +0000
Commit:     Eray Aslan <>
CommitDate: 2021-11-19 11:12:44 +0000

    mail-mta/postfix: cleanup
    Package-Manager: Portage-3.0.28, Repoman-3.0.3
    Signed-off-by: Eray Aslan <>

 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(-)
Comment 3 John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2021-11-19 12:44:13 UTC
Thanks Eray!