[exim-dev] [Bug 3063] "SMTP Smuggling" attack

Pàgina inicial
Delete this message
Reply to this message
Autor: Exim Bugzilla
Data:  
A: exim-dev
Assumptes vells: [exim-dev] [Bug 3063] New: Partially vulnerable to "SMTP Smuggling" if pipelining is enabled
Assumpte: [exim-dev] [Bug 3063] "SMTP Smuggling" attack
https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #16 from Simon Arlott <bugzilla.exim.simon@???> ---
(In reply to Viktor Dukhovni from comment #14)
> (In reply to Simon Arlott from comment #13)
> >
> > Jeremy, you've still not explained why Exim is now changing message content
> > like this. Postfix and Sendmail don't do it.
>
> Well, Postfix does in fact change message content when, for example, folding
> overly long headers or body lines, in order to ensure RFC-compliant SMTP
> output.
> In this case a line-break + space is inserted, and even without attempting
> to find a semantically appropriate context, garbage-in, garbage-out.
>
> So it wouldn't be entirely unprecedented to replace non-conformant input
> with a plausible best-effort approximation.


You could say the same thing about <LF>.<LF>, which is the cause of this
problem to begin with. It could allow new attacks based on adding and removing
headers.

Incoming message with a second subject header hidden in what looks like the
message body:

```
Received: ...<CRLF>
X-Placeholder1: A<LF>
Subject: A<CRLF>
<LF>
X-Placeholder2: B<CRLF>
Subject: B<CRLF>
<CRLF>
Message body<CRLF>
.<CRLF>
```

Spooled message with alternative subject header exposed:

```
Received: ...
Received: ...
X-Placeholder1: A Subject: A
X-Placeholder2: B
Subject: B

Message body
```

> As a result, while both <LF> and <CRLF> were accepted as line endings on
> input (leading to a "Normal" queue file record), the output is <CRLF>
> terminated either way. So it would perhaps be more natural to canonicalise
> <LF>.<LF> to <CRLF>.<CRLF> (but without treating it as end-of-message!).
> The result would then be subject to dot-stuffing (SMTP transparency) on
> output.


I think this is the approach that should be taken.

> One might accept <LF>.<LF> as message end only from clients whose "EHLO" and
> all subsequent SMTP commands up to and including "DATA" are <LF> terminated.
> This allows some legacy unix-native SMTP clients to continue to work, while
> requiring RFC-conformant line-endings from all others.


This could be implemented by checking that no <CR> character has been received
anywhere in the plaintext of the connection (without needing to specifically
check line endings on every command).

A host list or expanded configuration variable would allow it to be accepted
only from specific clients.

(It could exclude checking the message content itself because a message with
CRLF line endings could be sent through an SMTP client that only uses LF line
endings, but that allows a form of SMTP smuggling.)

--
You are receiving this mail because:
You are on the CC list for the bug.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@???
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/