[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Dec 2023 13:42:49 -0500 (EST)
From: Stuart D Gathman <stuart@...hman.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: New SMTP smuggling attack
On Sat, 23 Dec 2023, Alexander E. Patrakov wrote:
>> I'm trying to make sense of it - where's the compromise of the
>> Confidentiality, Integrity or Availability of the affected mail
>> servers?
>>
>
> The integrity of the sender's identity, as a minimum, is compromised
> here. Normally, when relaying mail, servers add a "Received:" header
> that specifies where they received the connection from. This allows
> tracking down the true origin of the message. The smuggled message
> does not have such a header and thus misrepresents the vulnerable
> relay as the ultimate sender. Additionally, if the relay has
> destination-based deny lists that deny some but not all addresses on
> the destination domain, they are sidestepped.
This is certainly a bug, but the currently reality is that
authentication involves SPF, DKIM, and other schemes - and does not
solely rely on headers. So can this "delete some headers" attack
compromise these authentication schemes?
I don't have a PoC, but I think so. If the original sender can indeed
convince the victim to relay their message, the victim will sign it
using their DKIM key - missing header fields and all. Relays will
typically alter the MAIL FROM so that SPF authentication passes.
But, that first "If" is the kicker. Any mail admin these days is very
careful about who can relay through their server. If they are relaying
at all, it is for a customer, partner, or buddy.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
