Summary: Depending on how SMTP servers/software are configured to interpret the end-of-data sequence (e.g., <CR><LF>.<CR><LF>), an attacker can break out of the message data to "smuggle" SMTP commands to send spoofed emails that pass SPF checks. Description: By exploiting interpretation differences of the SMTP protocol, it is possible to smuggle/send spoofed e-mails - hence SMTP smuggling - while still passing SPF alignment checks. During this research, two types of SMTP smuggling, outbound and inbound, were discovered. These allowed sending spoofed e-mails from millions of domains (e.g., admin[@]outlook.com) to millions of receiving SMTP servers (e.g., Amazon, PayPal, eBay). Identified vulnerabilities in Microsoft and GMX were quickly fixed, however, SEC Consult urges companies using the also affected Cisco Secure Email product to manually update their vulnerable default configuration. References: https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/ https://www.mail-archive.com/postfix-users@postfix.org/msg100901.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059230
Mitigations per Postfix: ----- As part of a non-responsible disclosure process, SEC Consult has published an email spoofing attack that involves a composition of different mail service behaviors with respect to broken line endings. A short-term fix may deployed now, before the upcoming long holiday: - Postfix 3.9 (stable release early 2024), rejects unuthorised pipelining by default: "smtpd_forbid_unauth_pipelining = yes". - Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same feature, but the "smtpd_forbid_unauth_pipelining" parameter defaults to "no". Setting "smtpd_forbid_unauth_pipelining = yes" may break legitimate SMTP clients that mis-implement SMTP, but such clients are exceedingly rare, especially when email is sent across the Internet. This short-term fix will stop the published form of the attack, but other forms exist that will not be stopped in this manner. The longer-term fix stops all forms of the smuggling attacks and is in testing. For most sites, this fix will be too late for deployment before a long holiday break, when typically production changes are not allowed until January.
Mitigations for Sendmail, per OSS thread: ----- sendmail 8.18.0.2 has options to handle this too, e.g., Accept only CR LF . CR LF as end of an SMTP message as required by the RFCs when the new srv_features option 'o' is used. And for those who read the source code there's also an FFR: /* enable checking for "bare LF" in message */ "_FFR_BARE_LF",
Created postfix tracking bugs for this issue: Affects: fedora-all [bug 2255565] Created sendmail tracking bugs for this issue: Affects: fedora-all [bug 2255566]
fyi, postfix 3.8.4, is out today, with fix that addresses the Smuggling Vulnerability, From: postfix-announce Sent: at Friday, Dec 22, 2023, 11:30 AM EST To: postfix-announce Cc: postfix-users Subject: [pfx-ann] Postfix stable release 3.8.4 > [An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.8.4.html] > > Fixed with Postfix 3.8.4: > > * Security: this release adds support to defend > against an email spoofing attack (SMTP smuggling) on > recipients at a Postfix server. For background, see > https://www.postfix.org/smtp-smuggling.html. > > Sites concerned about SMTP smuggling attacks should enable this > feature on Internet-facing Postfix servers. For compatibility > with non-standard clients, Postfix by default excludes clients > in mynetworks from this countermeasure. > > The recommended settings are: > > # Optionally disconnect remote SMTP clients that send bare newlines, > # but allow local clients with non-standard SMTP implementations > # such as netcat, fax machines, or load balancer health checks. > # > smtpd_forbid_bare_newline = yes > smtpd_forbid_bare_newline_exclusions = $mynetworks > > The smtpd_forbid_bare_newline feature is disabled by default. NOTE also that 3.9.x is planned for a "soon" release ...
Postfix 3.8.5 (and patches for older supported releases as well) will come out soon, improving the solutions already implemented in 3.8.4. Postfix 3.9 will contain the same solutions, with the only difference that in 3.9 they will be enabled by default.
https://access.redhat.com/security/cve/CVE-2023-51764 links to this bug, so I hope this is an appropriate place to report issues with that documentation page. As noted by electronic_eel on #rocky-security Rocky Linux security channel, that page currently gives a mitigation that does not actually work on any RHEL distro. Specifically, it says: "The suggested mitigation involves rejecting unauthorized pipelining by default using the configuration option smtpd_forbid_unauth_pipelining = yes." It also says that none of RHEL6 to 9 will be fixed. However, even RHEL9's Postfix is too old to support the smtpd_forbid_unauth_pipelining option. Instead, the syntax that's supposed to work on the older Postfix in those distros is the other one also given at https://www.postfix.org/smtp-smuggling.html: > With all Postfix versions: > > main.cf: > smtpd_data_restrictions = reject_unauth_pipelining > smtpd_discard_ehlo_keywords = chunking, silent-discard I have not actually tested it, but I confirmed that "reject_unauth_pipelining" is found in the source tree that's used on RHEL9, unlike "smtpd_forbid_unauth_pipelining". I see there are few people (and only one from Red Hat?) CC'ed on this bug, but it's assigned to Product Security, so hopefully me posting this will reach the right people to fix the security documentation. However, since I am not sure, please reply and confirm that this has been received by someone who can act on it. Thanks!