A few days ago, some researchers announced a novel exploit in the SMTP protocol which they have called SMTP smuggling. There has been some breathless reporting about how it bypasses security measures, will end email as we know it, dogs and cats sleeping together, and so on. However, it seems to me to be something of a tempest in a teapot for the vast majority of server operators, or at least something the vast majority of operators cannot do anything about. (Most servers running an SMTP service are not email service providers.) Anyway, their vulnerability report is here if anyone wants the details from the horse’s mouth, so to speak.
The vulnerability described by the researchers is potentially real, but how widespread exploitable cases actually are is questionable. Basically, during the SMTP dialogue, the message text is terminated by a “.” on a line by itself. The protocol specifies that a line must be terminated by a carriage return followed by a line feed (CRLF). Many implementations will accept a bare line feed (LF), a bare carriage return (CR), or even some stuff with NUL bytes included. Mishandling NUL bytes is definitely a flaw. Permissive line termination can also be argued to be a flaw. However, these are not the actual flaw that allows for the vulnerability specified by SEC Consult.
The reason I think this is a tempest in a teapot for most operators is because of how the SMTP dialogue should be handled. An SMTP dialogue consists of the following phases:
- Connection, greeting, and protocol negotiation
- Possible authentication
- MAIL FROM (“I’m sending a message now”)
- RCPT TO (“The message is for this recipient”); this step may be repeated an arbitrary number of times
- DATA (“The message is this”), which is terminated by the dot on a line by itself as described above.
- At this point, the sender will end the dialogue (with a QUIT command or possibly just closing the connection) or start over from step 3, possibly with an intervening RSET command.
What SMTP smuggling does is escape from step (5) above early and cause SMTP commands embedded in the message data to be processed by the server. That sounds scary, right? Except for the fact that an attacker could just as easily connect to the server again and issue those commands normally. In other words, the fact that these SMTP commands can happen is not the vulnerability.
So what, then, is the problem? There are several scenarios that lead to problems, but they all boil down to one thing: improperly implemented filters or other security measures. That still sounds scary, right? This SMTP smuggling thing can be used to bypass the filters and checks on my mail server, right? Well, that depends. Rather than detail what is vulnerable, let me comment on what is not vulnerable.
If you run a mail server that uses a single mail transport agent (sendmail, postfix) with no proxies, and that software applies all its filters and other checks to every single message it receives over the network during an SMTP dialogue, your filters cannot be bypassed by SMTP smuggling. That means milters listing for MAIL FROM, RCPT TO, DATA, etc., will all function properly and will be applied to the smuggled message just as they would to the original message. This applies whether the messages are authenticated submissions or inbound messages from the network. If this is your situation, you’re no more vulnerable to spoofing or filter bypasses due to smuggling than you are due to standard SMTP connections.
If, on the other hand, you operate a complicated multiple stage email transport system where different parts of the system disagree on how to interpret line endings in the protocol, you may have a problem. This applies also if you have some sort of proxying appliance, subscribe to a filtering service of some kind, or similar situations as well. Basically, if you’re doing anything other than handling SMTP connections directly, you may have some exposure. Having such a system does not guarantee you have a problem, but it does mean you should verify it.
In the vulnerable case, email messages can potentially be injected into the mail stream after filtering or other checks have already been completed by a proxy or other service. If that proxy or service is strict about line endings but the subsequent server in the chain is not, the vulnerability becomes exploitable. That second server will usually trust connections from the proxy or filter service and accept that second smuggled message without any raising any eyebrows and then proceed merrily on its way.
So what does this allow? A vulnerable email delivery pipeline may allow injection of messages that would normally be rejected by filters or other measures. This is a real problem and does need to be corrected by the operators of such email delivery pipelines. This will typically be large service providers such as Google or Yahoo, or corporate mail systems that subscribe to front end security or filtering services.
If, however, your email system does not use anything other than a basic SMTP server with no proxy or other service in front of it, then your system is not vulnerable. So, for instance, if you have a single server running sendmail or postfix, SMTP smuggling won’t introduce any means to inject unauthorized messages into the mail stream even if your server is permissive about line terminators. In this case, you can safely wait for your usual software update stream to provide patched versions of your mail transport software.
Furthermore, as recipients of the smuggled messages, once they are injected into the mail system, there is nothing that can be done to mitigate it. Once the smuggling has happened, the message is indistinguishable from any other message floating around the internet.
Anyway, in conclusion, the vulnerability is not that SMTP servers may be permissive about line endings, even though being strict about such things does stop it in its tracks. The vulnerability is poorly implemented filters and mail delivery pipelines. Those filters and delivery pipelines need to be fixed properly because the next vulnerability might not be nearly so innocuous.