Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ