[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 May 2024 10:01:16 -0500
From: Mark Esler <mark.esler@...onical.com>
To: oss-security@...ts.openwall.com
Subject: Re: New SMTP smuggling attack
On 4/30/24 14:13, nightmare.yeah27@...ecat.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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
