Gregory's ServerWhat 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.
|
25 comments
 #exim is tracking this in their bug report at https://bugs.exim.org/show_bug.cgi?id=3063 and a fix has been committed at https://git.exim.org/exim.git/commit/5bb786d5ad568a88d50d15452aacc8404047e5ca - thx @QuatermassTools for the info! https://infosec.exchange/@QuatermassTools/111637108410087826 For #sendmail some mitigation details at https://www.openwall.com/lists/oss-security/2023/12/21/7  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 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". @lauren Better safe than sorry, IMHO. I have hardened my mail server against this and I see many other admins do the same. I also see the developers working hard to get fixes done and out. On the day before Christmas. Because SEC consult decided to only share their findings with "Big Mail" and then hoped for 6 months that others (CERT/CC) would inform other affected projects so they could focus on their presentation for 37C3. :(  @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.  @jwildeboer @QuatermassTools that's not a fix in exim but just papering over the decade old violation of enforcing proper smtp. @leah @QuatermassTools Well, that's kinda how we do e-mail since many years. In many parts it is a fragile pile of workarounds and compromises ... @jwildeboer @leah @QuatermassTools let's add SMTP to the pile - alongside BGP and DNS.  @antondollmaier (to avoid misunderstanding: FTP **is** still an issue) @jwildeboer  @jwildeboer reject_unauth_pipelining was already set in my config, must've been shipped that way in debian. Didn't see the other setting anywhere yet.  @jwildeboer I don't get it, for Postfix: Long-term fix A long-term fix is now available for Postfix 3.8.4, 3.7.9, 3.6.13 and 3.5.23. This stops all forms of the smuggling attacks on recipients at a Postfix server. It introduces a new optional feature that is disabled by default. --- why is this new security fix disabled by default?  @jwildeboer where can I read more about their excuse? On the surface this sounds like pretty shocking behaviour. @jwildeboer for anyone else getting here an embarrassingly quick search found me the answer https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/  |
The current workaround for #postfix is to add
#SMTP smuggling mitigation
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_discard_ehlo_keywords = chunking
to main.cf. See https://www.postfix.org/smtp-smuggling.html for more details.