Received-SPF: pass (google.com: domain of oss-security-return-30104-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) client-ip=193.110.157.125;
Mailing-List: contact oss-security-help@lists.openwall.com; run by ezmlm
Precedence: bulk
Reply-To: oss-security@lists.openwall.com
Date: Tue, 30 Apr 2024 21:42:43 +0200
From: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
To: oss-security@lists.openwall.com
Cc: Mark Esler <mark.esler@canonical.com>,
        Bastien =?iso-8859-1?Q?Roucari=E8s?= <rouca@debian.org>
Message-ID: <20240430194243.GA28076@unix-ag.uni-kl.de>
References: <20231221143630.GD14101@suse.de>
 <ZjBHOEHylGAaIo57@moon>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZjBHOEHylGAaIo57@moon>
Author: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
Subject: Re: [oss-security] New SMTP smuggling attack

Hi Mark,

On Mon, Apr 29, 2024 at 08:19:52PM -0500, Mark Esler wrote:
> 
> 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.

This is an interesting interpretation of RFC 5321, but I do not think
it follows the contents of said RFC.

> > 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.

Well, my reading of the RFC does not forbid this sequence.  RFC 5321
clearly does not require transforming this sequence into another sequence.

> 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_.

RFC 5321 section 4.1.1.4 (DATA (DATA)) states:

    "The mail data may contain any of the 128 ASCII character codes"

RFC 5321 section 4.5.2 (Transparency) states:

    "The mail data may contain any of the 128 ASCII characters."

One might think that there is some inconsistency with the "SHOULD"
in section 4.1.1.4.

One could also understand the text as allowing any ASCII character
(including NUL), but advising against the use of known problematic ones
(e.g., NUL) by cautious systems.

To put this differently: control characters are _not_ forbidden.
They are _explicitly_ allowed.

> 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.

RFC 5321 section 3.6.3 does not pertain to DATA contents.  RFC
5321 section 6.4 mentions the problem of inconsistent handling of
"irregularities", i.e., shall malformed messages be rejected, "repaired",
or delivered as-is insofar possible.

You to seem to advocate for "repair".  The "repair" strategy makes Cisco's
ESA vulnerable.  I would argue that rejecting messages is less insecure.

> 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.

Use of control characters is compliant, even though it may be problematic.

> 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?

Interesting questions.  Perhaps you could perform an experiment and
report on the results?

Perhaps email specifications can be improved to reject known problematic
content elements, e.g., NUL bytes?

Rejecting email for arbitrary reasons is common practice currently.
Rejecting email for containing unwanted characters or character sequences
might thus be acceptable.  Rewriting email contents seems to me to be
more problematic, but even that is routinely done nowadays (e.g., to
mark external messages).

> Feedback appreciated,

I would suggest to be rather careful when automatically rewriting
messages in new and unsuspected ways.

> 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

Best regards,
Erik