SMTP Smuggling

The SMTP smuggling security vulnerability can happen in two ways:

(1) An outgoing SMTP sending engine can be used to send smuggled SMTP commands and messages if one of the following are true:

• the SMTP sender does not perform dot stuffing
• the SMTP sender is strict in its interpretation of newlines when performing dot stuffing, only treating <CR><LF> as a newline indicator and not <LF>

GreenArrow is good here and protects you from performing an outgoing SMTP smuggling attack.

GreenArrow’s SMTP sender does perform dot stuffing and it considers both the <CR><LF> and <LF> character sequences to be end-of-line indicators. This prevents GreenArrow from sending smuggled SMTP commands or messages.

(2) An incoming SMTP service can accept smuggled messages if it is lenient in its interpretation of newlines when looking for the end-of-message indicator

GreenArrow is vulnerable here.

GreenArrow’s incoming SMTP server is lenient in what byte sequences it will interpret as signifying the end of a line. Both <CR><LF> and <LF> are accepted as end-of-line indicators – both of which can be used as part of the end-of-message indicator and when undoing dot-stuffing.

In other words, all of these four byte sequences are interpreted by GreenArrow as an end-of-message indicator:

1. <CR><LF>.<CR><LF>
2. <LF>.<LF>
3. <CR><LF>.<LF>
4. <LF>.<CR><LF>

A SMTP message can be “smuggled” when all of the following are true:

1. The SMTP sending engine or library is strict in its interpretation of what byte sequences constitute an end-of-line indicator and therefore does not dot-stuff the byte sequences #2, #3 or #4 above.
2. This SMTP sender talks to an SMTP server which is lenient in its interpretation of the end-of-line and end-of-message indicator (like GreenArrow) and supports SMTP pipelining by default (like GreenArrow).
3. The attacker can get the SMTP sending library to send a message with byte sequences #2, #3 or #4 above.

If all of these are true, then an attacker can “smuggle” additional SMTP commands and messages after the byte sequences #2, #3 or #4 above.

For an email sender, the problem requires allowing customers to specify content for email messages, such as when an Email Service Provider allows their customer to provide the HTML or Text of an email to be sent. If all of the above are true, then your customers could include smuggled SMTP messages or commands as part of their email messages, but these will be interpreted as SMTP commands coming from your authorized message injectors.

For example, if the customer provides the following as their “HTML” content

<p>this is the original message</p><CR><LF>
<LF>
.<LF>
MAIL FROM:<[email protected]><CR><LF>
RCPT TO:<[email protected]><CR><LF>
DATA<CR><LF>
<CR><LF>
Content of the smuggled message here!<CR><LF>
.<CR><LF>

then a second email will be created to [email protected] from [email protected].

Note: An Email Service Provider that does both of the following is unlikey to be vulnerable to SMTP smuggling: (1) stores messages provided by customers in <LF> newline format (the standard for UNIX servers), and (2) uses a SMTP sending library that converts the <LF> to <CR><LF> in the SMTP conversation and performs proper dot-stuffing.