[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZjBHOEHylGAaIo57@moon>
Date: Mon, 29 Apr 2024 20:19:52 -0500
From: Mark Esler <mark.esler@...onical.com>
To: oss-security@...ts.openwall.com
Cc: Bastien Roucariès <rouca@...ian.org>
Subject: Re: New SMTP smuggling attack
To mitigate future end-of-data sequence attacks, like SMTP Smuggling, MTAs
should comply with RFC 5321 section 4.1.1.4 [0] to strip control
characters other than <SP>, <HT>, <CR>, and <LF> in the DATA section of
SMTP messages.
> 4.1.1.4. DATA (DATA)
>
> The receiver normally sends a 354 response to DATA, and then treats
> the lines (strings ending in <CRLF> sequences, as described in
> Section 2.3.7) following the command as mail data from the sender.
> This command causes the mail data to be appended to the mail data
> buffer. The mail data may contain any of the 128 ASCII character
> codes, although experience has indicated that use of control
> characters other than SP, HT, CR, and LF may cause problems and
> SHOULD be avoided when possible.
e.g., `\r\n\x00.\r\n` _SHOULD_ become `\r\n.\r\n` and then (as per RFC
5321 section 4.5.2 [1]) dot-stuff the _forbidden_ sequences.
As per RFC 2119 section 3 [2], the word *SHOULD* implies *MUST* unless you
have a valid reason not to--which is never the case for these _forbidden_
sequences in DATA. This is why RFC 5321 4.1.1.4's _SHOULD avoid_ implies
_needs to strip_.
Also note that RFC 5321 section 3.6.3 [3] and section 6.4 [4] do not give
the OK to send along NUL or other control characters. These sections are
about _adding_ missing information, not preserving messages with
potentially damaging garbage.
Cheers to Pete Resnick for this clarification and explanation of RFC 5321.
This particular issue was first noted in SEC Consult's analysis of SMTP
Smuggling [5]:
> During the research we've also discovered some exotic inbound SMTP
> servers that interpret end-of-data sequences like
> <CR><LF>\x00.<CR><LF>, with "\x00" representing a null byte. With
> proprietary SMTP components and lots of different e-mail services
> intertwined it's hard to tell what is possible until an e-mail reaches
> its final destination.
>
> Even though SMTP smuggling might still be hiding in some places, we
> hopefully eliminated some big targets.
Stripping NUL and other control characters could have unforeseen
consequences. MTAs which errantly rely on non-compliant control characters
would break. Major MTAs are therefore sensibly resistant to enforcing RFC
5321 section 4.1.1.4.
What is the real world HAM:SPAM ratio of emails which include NUL? Would
it be safe to configure sendmail to `O RejectNUL=True` (which would break
RFC 2822 section 4 [6] by rejecting email which include NUL)?
What are the benefits and risks of stripping ASCII NUL and other control
characters from SMTP DATA?
Feedback appreciated,
Mark Esler and Bastien Roucariès
[0] https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.1.4
[1] https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.2
[2] https://datatracker.ietf.org/doc/html/rfc2119#section-3
[3] https://datatracker.ietf.org/doc/html/rfc5321#section-3.6.3
[4] https://datatracker.ietf.org/doc/html/rfc5321#section-6.4
[5] https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
[6] https://datatracker.ietf.org/doc/html/rfc2822#section-4
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.
