Received-SPF: pass (google.com: domain of oss-security-return-30141-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: Thu, 9 May 2024 19:45:29 +0200
From: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
To: oss-security@lists.openwall.com
Message-ID: <20240509174529.GA31480@unix-ag.uni-kl.de>
References: <20231221143630.GD14101@suse.de>
 <ZjBHOEHylGAaIo57@moon>
 <20240430224823.uA8Nr1Cp@steffen%sdaoden.eu>
 <20240502182146.ygWZjB-Z@steffen%sdaoden.eu>
 <20240502195319.GA19209@openwall.com>
 <ZjuTvJ5sifwGhs2q@moon>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZjuTvJ5sifwGhs2q@moon>
Author: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
Subject: Re: [oss-security] New SMTP smuggling attack

Hi,

On Wed, May 08, 2024 at 10:01:16AM -0500, Mark Esler wrote:
> [...]
> 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)."

This section of the RFC explicitly states that any ASCII character is
allowed (see the first sentence you omitted from your quote).  Any ASCII
character includes NUL.  Stripping the NUL violates the standard.
This is obvious.  The RFC text is clear.

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

The Cisco ESA has been called out in the original SMTP smuggling report
as facilitating SMTP smuggling attacks, thus it is useful as an example.
It provides an example where a side-effect of rewriting email content is
vulnerability to "SMTP smuggling".  The important part is that rewriting
email content might have unintended side-effects, independent of RFC
compliance.

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

The one and only "forbidden" sequence is "<CRLF>.<CRLF>".
The one and only sequence to be "dot stuffed" is "<CRLF>.<CRLF>".

I think that "forbidden" is a bad choice of words.  It does not mean that
some authority has "forbidden" sending this sequence inside an email,
but that SMTP needs a way to transparently transport the "forbidden"
sequence for the user who is explicitly *allowed* to send it:

    "To allow all user composed text to be transmitted transparently"

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

Best regards,
Erik