Wietse Venema via Postfix-users:
> Rejecting stray <CR> and <LF> while receiving mail will prevent
> Postfix from receiving "smuggled" SMTP commands after a malformed
> end-of-data sequence, and thus, it will prevent Postfix from
> forwarding them.
> 
> So would rejecting an SMTP command pipelining protocol violation
> when the SMTP server receives a "smuggled" DATA command that is
> immediately followed by message content, but an attacker may
> try to position DATA<CR><LF> immediately before a packet boundary.

Unfortunately, the path to hell is paved with partial workarouds.

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>

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>

If my suspicion is correct, a dwnstream server may receive the
normal and suggled content as two separate messages.

Conclusion: for Postfix, rejecting malformed line endings is the
way to go. That includes malformed line endings inside BDAT.

        Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to