Mailing List Archive

https://bugs.exim.org/show_bug.cgi?id=3063

Simon Arlott <bugzilla.exim.simon@arlott.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |---
Status|RESOLVED |REOPENED

--- Comment #7 from Simon Arlott <bugzilla.exim.simon@arlott.org> ---
> Dec 2023: getting a site to send a body including an "LF . LF" sequence
> followed by SMTP commands is a possible "smtp smuggling" attack. If
> the first (header) line for the message has a proper CRLF then enforce
> that for the body: convert bare LF to a space.

This still doesn't comply with RFC5321 because it allows <LF>.<LF> to end the
message if the first header line ends with <LF>.

I expect that converting <LF> to a space is going to lead to further security
or interoperability problems because it will mean Exim will merge two lines in
a <CRLF>-based message if there's an <LF> in the middle of them, potentially
changing the meaning of the message by merging two or more header lines
together or merging the body with the headers.

Can't it just accept the message as-is, using dot duplication if the entire
line is "."?

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3063

Jeremy Harris <jgh146exb@wizmail.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED

--- Comment #8 from Jeremy Harris <jgh146exb@wizmail.org> ---
(In reply to Simon Arlott from comment #7)
> This still doesn't comply with RFC5321 because it allows <LF>.<LF> to end
> the message if the first header line ends with <LF>.

That is deliberate, as there are use-cases that require it.

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #9 from Simon Arlott <bugzilla.exim.simon@arlott.org> ---
You've not answered my other query on why Exim is replacing LF with a space.

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #10 from Ian <nobrowser@gmail.com> ---
(In reply to Jeremy Harris from comment #6)
> Security release 4.97.1 includes the relevant changes.

Do any of these changes affect the octets which a transport filter sees? I have
some suspect occurrences after upgrading (but not pointing a finger yet).

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #11 from Ian <nobrowser@gmail.com> ---
(In reply to Jeremy Harris from comment #8)
> (In reply to Simon Arlott from comment #7)
> > This still doesn't comply with RFC5321 because it allows <LF>.<LF> to end
> > the message if the first header line ends with <LF>.
>
> That is deliberate, as there are use-cases that require it.

Can we have a configuration knob to disable it? Maybe even disable the LF
ending headers.

I am up for coding it.

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #12 from Jeremy Harris <jgh146exb@wizmail.org> ---
(In reply to Ian from comment #10)
> (In reply to Jeremy Harris from comment #6)
> > Security release 4.97.1 includes the relevant changes.
>
> Do any of these changes affect the octets which a transport filter sees? I
> have some suspect occurrences after upgrading (but not pointing a finger
> yet).

Not directly, but if Exim is sending messages that it has previously
received, the changes that are in the receive path would affect those
messages - so if you are using a transport filter...

(In reply to Ian from comment #10)
> Can we have a configuration knob to disable it?

> I am up for coding it.

It doesn't seem technically infeasible. I trust you have read around the
relevant comments in the code regarding the support, and are willing to
keep both pieces when it breaks - and include testcases for the testsuite,
and maintain the new code for the forseeable future.

Please open a separate wishlist item for tracking this.

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #13 from Simon Arlott <bugzilla.exim.simon@arlott.org> ---
(In reply to Simon Arlott from comment #7)
> > Dec 2023: getting a site to send a body including an "LF . LF" sequence
> > followed by SMTP commands is a possible "smtp smuggling" attack. If
> > the first (header) line for the message has a proper CRLF then enforce
> > that for the body: convert bare LF to a space.
>
> I expect that converting <LF> to a space is going to lead to further
> security or interoperability problems because it will mean Exim will merge
> two lines in a <CRLF>-based message if there's an <LF> in the middle of
> them, potentially changing the meaning of the message by merging two or more
> header lines together or merging the body with the headers.
>
> Can't it just accept the message as-is, using dot duplication if the entire
> line is "."?

Jeremy, you've still not explained why Exim is now changing message content
like this. Postfix and Sendmail don't do it.

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #14 from Viktor Dukhovni <viktor1dane@dukhovni.org> ---
(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.

That said, Postfix stores message content lines as "records", they have neither
"LF" nor "CRLF" endings, they're either "Normal" records (complete lines to be
<CRLF> terminated on output) or "Continued" records (line fragments, to which
the next record is appended on output).

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.

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.

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #15 from Ian <nobrowser@gmail.com> ---
(In reply to Jeremy Harris from comment #12)
> (In reply to Ian from comment #10)
> > (In reply to Jeremy Harris from comment #6)
> > > Security release 4.97.1 includes the relevant changes.
> >
> > Do any of these changes affect the octets which a transport filter sees? I
> > have some suspect occurrences after upgrading (but not pointing a finger
> > yet).
>
> Not directly, but if Exim is sending messages that it has previously
> received, the changes that are in the receive path would affect those
> messages - so if you are using a transport filter...
>
> (In reply to Ian from comment #10)
> > Can we have a configuration knob to disable it?
>
> > I am up for coding it.
>
> It doesn't seem technically infeasible. I trust you have read around the
> relevant comments in the code regarding the support, and are willing to
> keep both pieces when it breaks - and include testcases for the testsuite,
> and maintain the new code for the forseeable future.
>
> Please open a separate wishlist item for tracking this.

Reading the code in receive.c, I'm having some ... second thoughts :-P

But maybe, and yes I understand that testcases are required.

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #16 from Simon Arlott <bugzilla.exim.simon@arlott.org> ---
(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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/