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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ