|
Message-ID: <20200423181234.GA23035@openwall.com> 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.