[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Apr 2020 20:12:34 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Wietse Venema <wietse@...cupine.org>
Subject: Re: spoofing of local email sender via a homoglyph attack
On Thu, Apr 23, 2020 at 07:03:14PM +0300, PromiseLabs Pentest Research wrote:
> I am not sure that the "from" header applies to user probing, as the
You mean the MAIL FROM aka envelope-from.
> actual mail server configuration on which I'm testing would accept any
> user as a sender:
>
> # nc -v *** OMITTED *** 25
> Connection to *** OMITTED *** 25 port [tcp/smtp] succeeded!
> 220 *** OMITTED *** ESMTP Postfix
> mail from: userdoesnotexists@...get.com
> 250 2.1.0 Ok
> rcpt to: test@...get.com
> 550 5.1.1 <test@...get.com>: Recipient address rejected: User unknown in
> local recipient table
> rcpt to: j??hn.doe@...get.com
> 550 5.1.1 <j??hn.doe@...get.com>: Recipient address rejected: User
> unknown in local recipient table
> rcpt to: existing.user@...get.com
> 250 2.1.5 Ok
>
> However, a non-existing user would not be accepted in the "rcpt-to"
> header, so this is another possible vector. This was discovered while
> doing a black box test on one of our clients, and it should be noted
> that the VRFY command has been enabled on the server, hence there was no
> reason to look for another way. However I'm unaware whether disabling
> VRFY would alter this behaviour. As you can see, the reported issue
> itself is may be actually due to the possibility of relaying a local
> email from a non-existing user.
>
> Having said this, if not then I assume then you are correct, in case we
> take the "to" header into consideration in relation to user probing,
> unless I'm missing your logic.
I actually meant probing via the "Sender address rejected: not logged
in" messages, which while delivered in response to a RCPT TO depend on
the MAIL FROM address. However, as Wietse tells us this merely probes
the smtpd_sender_login_maps table, so is very limited and
configuration-specific. Besides, as Wietse and you correctly remind us,
the possibility to probe for valid addresses via RCPT TO is in practice
unavoidable on modern Internet. So the point of blocking probing of
which sender addresses can vs. can not (do not need to) authenticate is
moot given that in typical setups those addresses are also potential
recipient addresses and thus could also be probed via RCPT TO.
What you reported originally, where you bypass something that just
happens that way in some configurations and wasn't meant to provide any
security against sender address spoofing, looks like even less of an
issue to me.
Does anyone see any reasonable action on these (non-)issues? If not, I
think the CVE should be rejected. It's a case of "works as intended."
> >>>>> Use CVE-2020-12063.
Alexander
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.
