It was found that Berkeley DB reads the DBCONFIG configuration file from the current working directory by default. This happens when calling dbcreate() with dbenv=NULL; or using the dbmopen() function.

References:

http://seclists.org/oss-sec/2017/q2/452 http://www.postfix.org/announcements/postfix-3.2.2.html

Proposed patch:

http://seclists.org/oss-sec/2017/q2/475

Last updated 13 May 2026

Postfix before 3.8.16, 3.9 before 3.9.10, and 3.10 before 3.10.9 sometimes allows a buffer over-read and process crash via an enhanced status code that lacks text after the third number.

The postfix.postinst script in the Debian GNU/Linux and Ubuntu postfix 2.5.5 package grants the postfix user write access to /var/spool/postfix/pid, which might allow local users to conduct symlink attacks that overwrite arbitrary files.

DISPUTED postfixgroups.pl in Postfix 2.5.2 allows local users to overwrite arbitrary files via a symlink attack on the (1) /tmp/postfixgroups.stdout, (2) /tmp/postfixgroups.stderr, and (3) /tmp/postfixgroups.message temporary files. NOTE: the vendor disputes this vulnerability, stating "This is not a real issue ... users would have to edit a script under /usr/lib to enable it."

The STARTTLS implementation in Postfix 2.4.x before 2.4.16, 2.5.x before 2.5.12, 2.6.x before 2.6.9, and 2.7.x before 2.7.3 does not properly restrict I/O buffering, which allows man-in-the-middle attackers to insert commands into encrypted SMTP sessions by sending a cleartext command that is processed after TLS is in place, related to a "plaintext command injection" attack.

A heap-based buffer overread flaw was found in the way Postfix mail transport agent performed SASL handlers management for SMTP sessions, when the Cyrus SASL authentication was enabled. A remote attacker could use this flaw to cause Postfix smtpd server crash via specially-crafted SASL authentication request.

Note: The default configuration of Postfix mail transport agent, as shipped with Red Hat Enterprise Linux 4, 5, and 6 do not enable SASL support for SMTP authentication for mail clients (thus Postfix server instances using it are not vulnerable to this flaw).

Workaround: If your Postfix server configuration contains directive like:

smtpdsaslauthenable = yes

change 'yes' to 'no' or comment the whole line out not to be vulnerable to this flaw.

Multiple SQL injection vulnerabilities in Postfix Admin (aka postfixadmin) before 2.3.5 allow remote authenticated users to execute arbitrary SQL commands via (1) the pw parameter to the pacrypt function, when mysqlencrypt is configured, or (2) unspecified vectors that are used in backup files generated by backup.php.

Postfix before 2.3.15, 2.4 before 2.4.8, 2.5 before 2.5.4, and 2.6 before 2.6-20080814, when the operating system supports hard links to symlinks, allows local users to append e-mail messages to a file to which a root-owned symlink points, by creating a hard link to this symlink and then sending a message. NOTE: this can be leveraged to gain privileges if there is a symlink to an init script.

DISPUTED A certain Postfix 2.10.1-7 package could allow an attacker to send an email from an arbitrary-looking sender via a homoglyph attack, as demonstrated by the similarity of \xce\xbf to the 'o' character. This is potentially relevant when the /etc/postfix/senderlogin feature is used, because a spoofed outbound message that uses a configured sender address is blocked with a "Sender address rejected: not logged in" error message, but a spoofed outbound message that uses a homoglyph of a configured sender address is not blocked. NOTE: some third parties argue that any missed blocking of spoofed outbound messages - except for exact matches to a sender address in the /etc/postfix/senderlogin file - is outside the design goals of Postfix and thus cannot be considered a Postfix vulnerability.

Last updated 24 July 2024

When mailmaxuseripconnections is set (default 10) and reached, submission-login can crash with epoll() panic caused by file descriptor handling issues. If running in high-security mode (default for community releases), only the new submission connection gets terminated. If running in high-performance mode (default for Pro releases), all connections handled by the submission-login process will be terminated. The crashes can cause failure for user to send a message, or it can cause duplicate messages to be sent. If TLS is not used (in the backend server processing the submission), duplicate deliveries cannot happen, because the crash can only happen at AUTH stage. Limit the number of connections handled by single submission-login process. This has a performance impact though. Update to non-vulnerable version. No publicly available exploits are known.

A heap-based buffer overread flaw was found in the way Postfix mail transport agent performed SASL handlers management for SMTP sessions, when the Cyrus SASL authentication was enabled. A remote attacker could use this flaw to cause Postfix smtpd server crash via specially-crafted SASL authentication request.

Note: The default configuration of Postfix mail transport agent, as shipped with Red Hat Enterprise Linux 4, 5, and 6 do not enable SASL support for SMTP authentication for mail clients (thus Postfix server instances using it are not vulnerable to this flaw).

Workaround: If your Postfix server configuration contains directive like:

smtpdsaslauthenable = yes

change 'yes' to 'no' or comment the whole line out not to be vulnerable to this flaw.

Postfix 2.4 before 2.4.9, 2.5 before 2.5.5, and 2.6 before 2.6-20080902, when used with the Linux 2.6 kernel, leaks epoll file descriptors during execution of "non-Postfix" commands, which allows local users to cause a denial of service (application slowdown or exit) via a crafted command, as demonstrated by a command in a .forward file.

Postfix 2.5 before 2.5.4 and 2.6 before 2.6-20080814 delivers to a mailbox file even when this file is not owned by the recipient, which allows local users to read e-mail messages by creating a mailbox file corresponding to another user's account name.

On 4/30/24 14:13, nightmare.yeah27 () aceecat org wrote: What is the benefit of stripping versus the much more natural option of rejecting such messages? This applies to <CRLF>.<CRLF> and RFC 5321 section 4.5.2 as well.

Postfix' CVE-2023-51764 patchset adds options to normalize (default), note, reject, or ignore bare newlines: cleanupreplacestraycrlf = default:yes smtpdforbidbarenewline = default:normalize smtpdforbidbarenewlineexclusions = default:$mynetworks (See Postfix' HISTORY file for more context.)

To get back to your question, these all have usecases. What should be the default is described in RFC 5321. Offering options and using the RFCs sane default seems like a fair balance.

On 4/30/24 14:42, Erik Auerswald wrote: Well, my reading of the RFC does not forbid this sequence. RFC 5321 clearly does not require transforming this sequence into another sequence. I should have initially clarified that "forbidden" pattern refers to RFC 5321 section 4.5.2: Without some provision for data transparency, the character sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. In general, users are not aware of such "forbidden" sequences. To allow all user composed text to be transmitted transparently, the following procedures are used: o Before sending a line of mail text, the SMTP client checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line. o When a line of mail text is received by the SMTP server, it checks the line. If the line is composed of a single period, it is treated as the end of mail indicator. If the first character is a period and there are other characters on the line, the first character is deleted.

I believe "<CRLF><NUL>.<CRLF>" is a forbidden sequence. Resnick's response to this sequence is: "Yes, the sending MTA should strip the NUL (as per RFC 5321 section 4.1.1.4) and then dot-stuff the dot on the line by itself (as per RFC 5321 section 4.5.2)." You to seem to advocate for "repair". The "repair" strategy makes Cisco's ESA vulnerable. I would argue that rejecting messages is less insecure. By default, Cisco ESA is not RFC compliant. Their "clean" option only replaces bare <CR> and <LF> characters with <CRLF>. So that <CR>.<CR> becomes <CRLF>.<CRLF>. Both of these are "forbidden" patterns and should be dot stuffed.

On 4/30/24 17:48, Steffen Nurpmeso wrote: Given that RFC 733 is from 1977 and RFC 822 is from 1982 i feel this entire thread is exaggerating. The history of EOD attacks makes the recent SMTP Smuggling attacks so surprising! It is hard to believe that SMTP servers were recently vulnerable to <CRLF>.<CRLF> variations and that others still are.

Thanks Solar :)

Mark Esler and Bastien Roucariès

End of life: 2/5/2022, Latest version: 3.3.22

End of life: 2/5/2022, Latest version: 3.3.22

End of life: 3/6/2026, Latest version: 3.7.22

End of life: 3/6/2026, Latest version: 3.7.22

Latest version: 3.8.20

Latest version: 3.8.20

Latest version: 3.9.14

Latest version: 3.9.14

End of life: 3/15/2020, Latest version: 3.1.15

End of life: 3/15/2020, Latest version: 3.1.15

End of life: 2/27/2019, Latest version: 3.0.15

End of life: 2/27/2019, Latest version: 3.0.15

End of life: 2/16/2025, Latest version: 3.6.20

End of life: 2/16/2025, Latest version: 3.6.20