Hi Tim, I work for CERT/CC where we run the VINCE platform, sorry this disclosure has brought some confusion on what happened and how.
In general, CERT/CC’s approach to coordinated disclosure is to ask researchers to first reach the vendors and contact us when they cannot reach them. We also extend the outreach when it is an issue of reaching many vendors that the researcher has no ability to find their contacts – so no public security page or bug page or standard reporting web page etc. Specifically for this Vulnerability Report or “Case”, we analyzed and understood the vulnerability was in SMTP inbound and outbound servers that incorrectly accept <CR>LF>.<CR><LF> combinations inside a message transaction after <DATA> statement and do not apply same policy while scanning the “smuggled” (embedded) email. On investigating products, we only found online services who did this, Postfix was not identified as vulnerable to the idea of applying policies in incongruent way to two emails that could be pipelined or submitted. However the issue was very different. SEC identified Cisco Ironport as vulnerable, but Cisco found it not to be “vulnerable” as they apply policies distinctly to each email that were submitted even when pipelined with <CR><LF> confusion for “smuggling”. SEC Consult testing had scenarios that were different from our understanding, such as an authenticated MSA (Mail Submission Agent) submitting email to another MTA that handle the non-standard ending of <CR><LF> and forwarded it along. Arguably the second server is at fault here for “SPF” signing two emails, nevertheless the vulnerability is due to the combinatorial or Composition Attack as Wietse has identified. We didn’t quite understand this form or attack, perhaps even SEC did not know which server exactly did the unmangling of emails as they tested against a live environment. I relayed to Wietse and Viktor what we understood and knew about the attack but obviously had not talked about the Composition issues as Wietse identified. When there is an impasse on a vulnerability disclosure that we are not able to identify clearly a product and a vendor as vulnerable, we encourage the researchers to write up a more like “Buyer beware” type blogs of known issues on the Internet. The whole idea was more like users be careful in trusting the From: address you see even if it is SPF verified. This has happened in the past for e.g., earlier Microsoft vulnerability of Reply-To abuse, turned more into an article on “Sender” and Reply-To related issues of trust here https://learn.microsoft.com/en-us/archive/blogs/tzink/what-do-we-mean-when-we-refer-to-the-sender-of-an-email But Alas the article revealed a lot more of practical examples of specifically Composition issues found when trying various Service Providers. I personally don’t feel like blaming anyone as the event is past and the assumption is all of us are working in good faith to reduce “risk” that is shared by the Internet community. Retrospectively, the most valuable thing we could have had is a Preview of the Blog privately to all vendors impacted before releasing it. This is something SEC could have done (or CERT/CC requested) that may have brought more clarity for what exactly SEC Consult is talking about (or how much bigger the research had become) and potentially delayed the disclosure to give Vendors more time. Thanks Vijay From: Wietse Venema via Postfix-users <postfix-users@postfix.org> Date: Friday, December 22, 2023 at 7:57 PM To: Postfix users <postfix-users@postfix.org> Subject: [pfx] Re: SMTP Smuggling disclosure process & VINCE Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe. Tim Weber via Postfix-users: > Hi Wietse, > > thanks for getting back to me so quickly. Please rest assured that > I'm not looking for someone to blame. My motivation is to try to > find out whether SEC's release process really has been as responsible > as they claim: Sorry, you are talking to the wrong person. I can make statements only based on the information that I received prior to the attack's publication. Wietse _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
