oss-sec mailing list archives
Re: New SMTP smuggling attack
From: Mark Esler <mark.esler () canonical com>
Date: Wed, 8 May 2024 10:01:16 -0500
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: ``` cleanup_replace_stray_cr_lf = default:yes smtpd_forbid_bare_newline = default:normalize smtpd_forbid_bare_newline_exclusions = 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
Attachment:
signature.asc
Description:
Current thread:
- Re: New SMTP smuggling attack Mark Esler (Apr 30)
- Re: New SMTP smuggling attack nightmare . yeah27 (Apr 30)
- Re: New SMTP smuggling attack Erik Auerswald (Apr 30)
- Re: New SMTP smuggling attack Steffen Nurpmeso (Apr 30)
- Re: New SMTP smuggling attack Steffen Nurpmeso (May 02)
- Re: New SMTP smuggling attack Solar Designer (May 02)
- Re: New SMTP smuggling attack Mark Esler (May 09)
- Re: New SMTP smuggling attack Erik Auerswald (May 09)
- Re: New SMTP smuggling attack Steffen Nurpmeso (May 02)