oss-sec mailing list archives
Re: New SMTP smuggling attack
From: Mark Esler <mark.esler () canonical com>
Date: Mon, 29 Apr 2024 20:19:52 -0500
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
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)