[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9B221D9A-9D10-4F3D-9F1A-077A7EBFB31F@redhat.com>
Date: Wed, 07 May 2014 09:47:20 -0600
From: "Vincent Danen" <vdanen@...hat.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: Postfix bounces arbitrary content
On 05/06/2014, at 19:57 PM, cve-assign@...re.org wrote:
>> take 5,000 randomly selected articles from my local news spool, and
>> cause b.com to bounce all of them from bob@...om to postmaster@...om.
>> This will likely cause a.com to block incoming mail from bob@...om,
>> or from all of b.com
>
> It seems more likely that the default configuration would produce
> bounce messages with a header From: address starting with
> "MAILER-DAEMON@" and an empty envelope-sender address. In that case,
> blocking mail from bob@...om wouldn't accomplish anything. But it's
> conceivable that the a.com administrator would start blocking the IP
> address of the b.com SMTP server.
>
> That's a detail that doesn't have much effect on the CVE inclusion
> question.
>
> Originating a new message to report non-delivery is valid according to
> RFC 2821 section 6.1. It's not really the case that there's inherently
> an integrity impact.
>
> There could be a Postfix developer announcement that, according to
> their security policy, this is unintended behavior with an integrity
> impact. A CVE assignment would be possible in that case.
>
> (To summarize: just because the RFC 2821 section 6.1 behavior is
> allowed doesn't mean that it's a good idea. An SMTP server should
> minimize the situations in which outsiders can trigger an arbitrary
> volume of outbound SMTP traffic to arbitrary destination IP addresses.
> Non-deliverability should be detected within the original SMTP dialog,
> and this case of the Delivered-To: header doesn't seem impossible to
> detect. However, there might be some type of architectural motivation
> for not checking the Delivered-To: header within the original SMTP
> dialog. Even if it was originally intentional, the developer might
> accept a feature request to change it.)
This is perfect. Thank you. It also confirmed what I expected (and upstream should have its say here). I think that, given it was initially reported a decade ago, that that gives some hint as to how they may feel about it.
At any rate, thank you for your feedback.
--
Vincent Danen / Red Hat Security Response Team
Download attachment "signature.asc" of type "application/pgp-signature" (711 bytes)
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.
