On Tue, Dec 19, 2023 at 10:42:14AM -0500, Wietse Venema via Postfix-users wrote:
> First, there is one mistake in my last quoted paragraph above. In
> the smuggled commands, an attacker can avoid an SMTP command
> pipelining violation, by using use BDAT instead of DATA.
> Below I'm indenting the smuggling-related inputs:
>
> EHLO ...<CR><LF>
> MAIL FROM ...<CR><LF>
> RCPT TO ...<CR><LF>
> DATA<CR><LF>
> normal content
> <LF>.<CR><LF>
> MAIL FROM ...<CR><LF>
> RCPT TO ...<CR><LF>
> BDAT ...<CR><LF>
> smuggled content
> BDAT 0<CR><LF>
> <CR><LF>.<CR><LF> (command syntax error)
> QUIT<CR><LF>
The source of the problem is that it is technically valid to pipeline a
second mail transaction after the first without waiting for the initial
result, and BDAT removes the synchronisation point at "DATA". At least
one of these is IMNSHO a specification error.
The BDAT (CHUNKING) ESMTP extension was defined rather a long time ago,
in a less hostile environment. It SHOULD have specified that the first
BDAT be a pipelining pause, just like "DATA". Without that, the
receiving MTA is supposed to tolerate receiving a stream of pipelined
BDAT commands of indeterminate length (awaiting an RSET or QUIT) even
after rejecting all the recipients and the first BDAT command.
That said, I'd expect it is far easier to require a pause between the
end of one message and the start of another. While it is reasonable to
allow a pipelined QUIT or RSET after "DOT", anything else should require
resynchronisation (there's alreadya a resync after RSET and QUIT is of
course final).
I don't see a legitimate use-case for SMTP clients to stuff a stream of
pipelined messages down the wire without any intemediate pauses after
the initial EHLO. Is anyone aware of sending MTAs that do that?
[ It this is something only some MUAs do, then "message stuffing" could
be restricted to submission and trusted clients. ]
> Second, speaking of BDAT, I suspect that Microsoft's fix may still
> allow stray <LF> when the smuggler uses BDAT for the whole transaction.
> Again, I'm indenting the smuggling-related inputs:
>
> EHLO ...<CR><LF>
> MAIL FROM ...<CR><LF>
> RCPT TO ...<CR><LF>
> BDAT ...<CR><LF>
> normal content
> <LF>.<CR><LF>
> smuggled commands and content
> BDAT 0<CR><LF>
> QUIT<CR><LF>
[ That "BDAT 0" is of course "BDAT 0 LAST", or, more typically,
"BDAT <last segment length> LAST". ]
But the reported Microsoft "workaround" is that they won't transmit
<LF>.<LF> to a remote system that does not do BDAT, they will send
a non-BDAT <LF>.<CRLF>.
<quote from paper>
After a deeper analysis of outbound SMTP servers, a peculiarity in
Microsoft Outlook's (outlook.com) SMTP server was observed. When
trying to send an <LF>.<LF> sequence, the message does not get
transmitted, and the following error message is returned:
Remote server returned '550 5.6.11 SMTPSEND.BareLinefeedsAreIllegal;
message contains bare linefeeds, which cannot be sent via DATA and
receiving system does not support BDAT'
</quote from paper>
Note that Postfix supports BDAT, and Microsoft will presumably elect to
use it when available, so outlook.com->Postfix should never result in
SMTP message smuggling regardless of line endings, that requires either
the sending or receiving system to not support CHUNKING (BDAT).
> If my suspicion is correct, a dwnstream server may receive the
> normal and suggled content as two separate messages.
I don't see why. It shouldn't matter how Microsoft's MTA ends up
with a message containing "<LF>.<CRLF>" or (<LF>.<LF>), so long as
they refuse to send the violating sequence to a non-BDAT peer. The
issue seems to be that they didn't think to apply the logic to both
variants, censoring only <LF>.<LF>, but not <LF>.<CRLF>.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
