The #SMTPSmuggling attack is being mitigated and tracked in the following CVEs:
CVE-2023-51764 postfix
CVE-2023-51765 sendmail
CVE-2023-51766 exim
All three CVEs have been filed today by the community and NOT by SEC consult who discovered the flaw in June 2023 but decided to not share their findings with postfix, sendmail or exim. Only after they published their post on 2023-12-18, the communities have become aware and are now working hard to fix what is now more a 0day :(
What a wonderful way for open source developers to go into the holiday season. This gives the "push to prod on Friday" joke a whole new meaning. SEC consult made some sort of excuse for their behaviour of not sharing this earlier but will give a talk on the topic at 37C3 on day one nevertheless.
If you get Wietse Venema to say "The net result is that an unintended zero-day attack was published, before people had an opportunity to update their affected email systems." you know you have messed up ...
@jwildeboer I got an email a few minutes ago from a reader of my mailing lists who noted that he was one of the designers of the SPF/DMARC/DKIM ecosystem, pretty much agreeing with my assertion that this isn't really as big a deal as being made out, because so much spam comes now from completely legit (but "fake") domains that pass all these checks.
@lauren@jwildeboer I think the supposed issue is phishing not spam. But it's still email trying to solve an out-of-scope problem. If your employees can get tricked to disclose credentials by an email, the problem is not that you didn't write a sufficiently draconian filter to block the email. It's that you gave them phishable credentials.
@lauren Sure. I'd agree to that too. The bigger problem is that this flaw can severely damage the reputation of small(er) servers, getting them added to blacklists of the Big Mail oligopoly. That's why we mail admins of small servers are (forced to) always working hard to mitigate any possibility of that happening. But mitigations have been published by postfix, exim, sendmail. What bothers me is that this could have all been solved months ago, if done in a different way :(
@lauren And (at least according to some early checks) this flaw isn't limited to DMARC spoofing. It could potentially be used for phishing and other abusive attacks too. This is why sendmail, exim and postfix (and more, I guess) have decided to treat this with high priority.
@jwildeboer I don't see how it will make the blacklists any larger. Big Mail (to the extent they are affected) will fix it on their inbound, and the blacklists aren't likely to add servers to the lists that still can be verified via IP-based means like SPF. It's not like this can't be figured out. I haven't seen any sendmail mitigation, by the way, except something that might apply to the very latest version that doesn't even run widely.
@jwildeboer Anyway, anything smaller servers can do is negligible. They can't do anything outbound to fix this. And at a small scale inbound won't matter much either in the scheme of things compared with "Big Mail".
@tony@jwildeboer
> As our research was accepted at this year's 37C3 conference (info received on 3rd December) and we still thought that Cisco users should be warned about the vulnerable default configuration, we decided to publish our research before the conference and holidays in order to provide administrators time to re-configure their Cisco configuration.
Add comment