[exim-dev] [Bug 3063] Partially vulnerable to "SMTP Smugglin…

Top Page
Delete this message
Reply to this message
Author: Exim Bugzilla
Date:  
To: exim-dev
Old-Topics: [exim-dev] [Bug 3063] New: Partially vulnerable to "SMTP Smuggling" if pipelining is enabled
Subject: [exim-dev] [Bug 3063] Partially vulnerable to "SMTP Smuggling" if pipelining is enabled and chunking is disabled/unused
https://bugs.exim.org/show_bug.cgi?id=3063

--- Comment #3 from Viktor Dukhovni <viktor1dane@???> ---

(In reply to Jeremy Harris from comment #2)
> (In reply to Viktor Dukhovni from comment #1)
> > Does Exim enforce pipelining conformance by default?
>
> In general yes, but specifically for the 354 "DATA go-ahead", not
> by default. It's possible to induce one.
>
> I could see some value in a change to always enforce.


That would likely be prudent.


> > Also, I should note that (as specified in RFC1830) BDAT is NOT the last
> > command in a pipeline group, and so Exim will accept two messages via a
> > transaction of the form:
> >
> >    MAIL FROM:<sender>
> >    RCPT TO:<nobody>
> >    DATA

>
> Um, that was DATA and not BDAT.


That's DELIBERATE. The BDAT in question is in the BODY of the upstream message
(below), preceded by <LF>.<LF>. We need DATA from the upstream system to make
some variant of <CRLF>.<CRLF> be end-of-message, but then its SMTP smuggling
payload can use BDAT to bypass any pipelining enforcement.

>
> >    From: Some Sender <sender>
> >    To: Discarded Rcpt <nobody>
> >    Subject: ...

> >
> >    <Some Message>
> >    <LF>.<LF>

>
> and IF that gets treated as the dot closing off data, such that the
> following are taken as commands for a further message:
>
> >    MAIL FROM:<forged-sender>
> >    RCPT TO:<real-rcpt>
> >    BDAT <length> LAST
> >    From: Forged Sender <forged-sender>
> >    To: Real Rcpt <real-rcpt>
> >    Subject: Wire all your assets to me

> >
> >    <Phishing attack>
> >    QUIT

>
> ... that "phishing attack" could just as easily have been sent
> as a sole message. It will still be subject to all the same
> Access Control List operations, either way.


But the scenario in question assumes that the victim of forgery has DMARC, and
that the sending system would normally restrict the alleged "From:" address (as
is the typical case for submission via public email providers, hosting many
customer domains, including perhaps their own).

In this attack scenario, the sending system is unaware that there's a second
message in the body of the first, and the alignment of "From:" with the sender
credentials is not enforced, but SPF-based DMARC checks still pass...

--
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/