21Nails: Multiple Critical Vulnerabilities in Exim Mail Server | Hacker News Reader

21Nails: Multiple Critical Vulnerabilities in Exim Mail Server

exim.org

26 pointsupofadown27 comments

A lot of people believe that Exim is a, let's say, 2nd generation MTA, like qmail and Postfix, both of which were written with security in mind as a reaction to the Sendmail security debacle --- Sendmail holding the title for many years in the 1990s as the most popular and important vector for remote code execution on the Internet.

But Exim is much more closely related to Sendmail (I believe it's technically a fork of Smail, which was a Sendmail competitor) than to Postfix or qmail. It parses haphazardly and, as, you can see, it isn't meaningfully privilege-separated. It rides atop all the quirks of the circa-1999 standard C library.

Nobody should be running Exim in 2021.

In reality, the world is moving on past even the 2nd generation MTAs, which, though their track records are pretty strong, are still built in memory-unsafe languages. Serverside software written in Java, Go, and Rust handle workloads far more difficult than even an ambitious Postfix deployment deals with. Still: it's baffling how we've ended up in a place where Exim --- whose security has been a running joke since the 1990s --- is one of the most popular Unix MTAs. Nobody would have called this outcome in 1999!

The funniest part of this advisory starts at "Exim's memory allocator"; just read on for a special Exim bug class.

This is great work, and a great writeup.

"Nobody should be running Exim in 2021."

Maybe, yet it still shuffles a lot of email around the place. It deals with a lot of corner cases. When I say corner cases I mean orthogonality that might put off a top class mathematician fresh from fiddling with spherical cows in n dimensions. Email is not simply a bit odd but downright pathologically weird.

We all know what email is and it's just so simple. You can use telnet and point it at a smtpd and send a message. HELO me ... mail from: .... rcpt to: .... data .... . (blah blah message_id:x)

Yet, for some reason an MTA is a massive edifice of oddities. You could make an MTA that simply shuffles a text stream from a to b but what sort of text stream? MIME encoded doesn't mean what you think it does in quite a lot of cases. MIME is nearly formally defined but as always the beauty is in the eye of the programmer.

As well as moving text around a bit, MTAs are asked to do a firewall's role and also integrate with AV and anti spam. Ideally they should also be capable of reading minds.

I could go on.

Exim is probably not the most beautiful example of modern security practice but it is actively developed by people who do give a shit and are trying to keep something that no one will ever allow to go away working, as best they can. RFC822 (etc, int al, ad nauseam) can never be considered a modern communication technique that will ever lend itself to secure programming practices. Email is never going to be "secure" by worrying about what language an MTA is written in and I think you might have forgotten the worst part of the security circus here: The end user.

You can call out the MTA as much as you like but your Go or Rust jobbie will still deliver an email that my Financial Controller clicks on and dumps my bank account.

Nobody should be using email in 2021 (discuss ... 8)

You could break the glass and roll back the year numbers on this comment, switch the "Exim" badge to "Sendmail", and sell this as an authentic comp.security.unix post circa 1996. I think we can see in retrospect what an absolute debacle that was for the Internet. The difference is that today we have better options. Postfix is written in C, and none of us should be comfortable with that, but it's not macraméd out of heap overflows, and its heap doesn't start with a blob that will shell-expand to system commands.

>Postfix is written in C, and none of us should be comfortable with that

qmail is written in C, and it has never had a serious security hole that I am aware of. Not all C code is unsafe.

64-bit qmail was remotely exploitable. The author believes a small address space (below 4 GB) was an adequate mitigation, but the code was confused and trying to do something unsafe.

https://lwn.net/Articles/820969/

One thing you can say for both Postfix and qmail is that they're written to avoid the problems of the C standard library. Exim is not.

> what an absolute debacle that was for the Internet

You make it sound like it ended the Internet or something. One could also argue (with only similar level of hyperbole) that it was sendmail which made the Internet a success. Obviously the truth is in between, but lets give credit where credit is due. Sendmail served us well in its time. It's not inherently the fault of its developers, that the Internet evolved to a much darker place over time.

We disagree on how big of a deal pervasive serverside memory corruption vulnerabilities have been. Easily a bigger problem than early-1990s congestion collapse.

> Serverside software written in Java, Go, and Rust handle workloads far more difficult than even an ambitious Postfix deployment deals with.

Can you suggest good options? If I want to run a MTA on my Debian box, what should I use in 2021?

Postfix is default in Ubuntu. It was the runner-up to the election that made Exim the default in Debian. And the possibility of weak security was raised at the time. The only reason it won was because Exim used less memory. A shame really, and if that debate had gone differently then I suspect nobody would be using Exim today.

Postfix if you need something with flexibility.

For just getting mail off the system to a central hub: dma or ssmtp.

Debian has an OpenSMTPD package. Dunno how well it runs on Linux. It has awesomely simple and straightforward configuration. I would be running it now but I wanted to do something relatively complicated. After evaluating the available choices I eventually settled on, you guessed it, Exim.

It's probably not so productive to comment on all the security holes over the years in MTAs. That said opensmtpd hasn't been unaffected by security issues either:

https://www.opensmtpd.org/security.html

In the past I ran a perl-based MTA, qpsmtpd, which was actually free of issues for the time I read it. That project was mothballed in favour of a node.js alternative (haraka). Of course both of these cheat by offloading delivery to something else - they're just the network layer, but very flexibly so.

I wish I had a better recommendation than Postfix, if you really need a general-purpose MTA. But absolutely not Exim.

> Nobody should be running Exim in 2021.

Nobody should be installing an MTA by default in 2021.

> is one of the most popular UNIX MTAs

Thanks to Debian and Ubuntu most probably? Default MTA and people don’t stray from defaults! Not sure the reason why it was chosen was appropriate. About 8-bit MIME clean-ness, no?

dpkg-reconfigure exim4-config to configure most common MTA use-cases and no Bat book to consume.

*UPDATE* - Apparently Ubuntu uses postfix by default. So maybe the % share will shift going forwards as more people use Ubuntu LTS installs in-lieu of Debian

Exim has had so many serious security vulns. No idea why it is the default in Debian over something far more secure like Postfix.

What do you think is the worst security vulnerability that email MTAs have to deal with? The MTA itself or the end user? The most secure smtpd will still deliver a nasty email.

Note also that someone has actually bothered to do an assessment and published results. Does your preferred MTA enjoy that sort of attention?

Debian has had many discussions over the years about this, they all devolved into bikeshedding about dropping an MTA from the default install vs switching to postfix etc.

Exim is full of bugs, but it is hard to switch to something else. I'd prefer some pragmatic mitigation instead.

Anybody using some general mitigations for exim, like running in chroot or in containers? How to set up such thing on CentOS?

DSA tracks which versions of exim4 have these fixes applied.

https://security-tracker.debian.org/tracker/source-package/e...

Please remember to update your mailservers.

The largest deployment of this will be web hosting companies running cPanel/WHM (ie, the majority of them). It's part of the default installation there.

Proving, again, that “given enough eyeballs, all bugs are shallow” is a lie.

I hate this maxim. It's my guess that it is only perpetuated by those who haven't worked in software professionally.

Only one of many falsehoods promoted by ESR, and far from the worst.

"Erhard Seminars Training"?

Reply on news.ycombinator.com