Gregory's Server#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
|
15 comments
  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) |
For #sendmail some mitigation details at https://www.openwall.com/lists/oss-security/2023/12/21/7