Bug 2255563 (CVE-2023-51764)

Summary: CVE-2023-51764 postfix: SMTP smuggling vulnerability
Product: [Other] Security Response Reporter: Robb Gatica <rgatica>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: geert, jskarvad, kyoneyam, pasik, solar, stefano.biagiotti
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: postfix 3.8.4, postfix 3.7.9, postfix 3.6.13, postfix 3.5.23 Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in some SMTP server configurations in Postfix. This flaw allows a remote attacker to break out email message data to "smuggle" SMTP commands and send spoofed emails that pass SPF checks. Out of the box, Postfix targets to accommodate older clients with faulty SMTP implementations due to which restrictions are not enforced in the default configuration. Appropriate mitigation strategies are mentioned in the appropriate section below.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2255565, 2255566, 2255870    
Bug Blocks: 2255562    

Description Robb Gatica 2023-12-21 21:58:42 UTC
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

Comment 1 Robb Gatica 2023-12-21 22:18:41 UTC
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.

Comment 2 Robb Gatica 2023-12-21 22:21:00 UTC
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",

Comment 3 Robb Gatica 2023-12-21 22:22:02 UTC
Created postfix tracking bugs for this issue:

Affects: fedora-all [bug 2255565]


Created sendmail tracking bugs for this issue:

Affects: fedora-all [bug 2255566]

Comment 5 pgnd 2023-12-22 17:45:57 UTC
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 ...

Comment 7 Geert Hendrickx 2024-01-10 15:25:00 UTC
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.

Comment 8 Alexander Peslyak 2024-01-17 16:16:25 UTC
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 e‚Äčlectronic_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!