Exim Off-By-one RCE: Exploiting CVE-2018-6789 with Fully Mitigations Bypassing | Hacker News Reader

Exim Off-By-one RCE: Exploiting CVE-2018-6789 with Fully Mitigations Bypassing

devco.re

54 pointspjmlp16 comments

It has never been a good idea to run Exim.

Running your own mail server has always been a pretty rough idea. Running an S-Mail (or, for that matter, Sendmail) derivative in 2018 just seems like asking for something bad to happen. With just two exceptions, C-language MTA servers have been the Internet's "Kick Me" sign since literally the inception of Internet hacking.

For reasons I do not understand, but that go all the way back to comp.security.unix days in the 1990s, there's a widespread belief that Exim is somehow a secure mail server. Exim has never been that. The two secure C-language MTAs are qmail and Postfix, both of which were designed, from the ground up, on day 1, to mitigate the kinds of vulnerabilities Sendmail has historically been vulnerable to (and which this vulnerability is an example of).

Don't run your own mail server. But if you have to, don't run a C-language mail server. But if you have to, run Postfix.

Don't run Exim.

> Don't run your own mail server.

Agreed on almost everything, but disagree on this; there's no reason why any reasonably competent and security-focused sysadmin can't run a secure Postfix or qmail server (although it's hard to run a secure version of qmail these days). In some ways, it's easier than back in the day (hello, letsencrypt!) and in some ways it's harder (DKIM, SPF, etc), but it's still doable and there are some excellent reasons for doing so.

(The rest of your advice is excellent.)

> Don't run Exim.

Absolutely agreed. I'm not sure why Debian opted to make it the default MTA over Postfix (but they also opted for systemd over runit, so..)

Postfix is nice, but the cognitive load of having to also understand and implement SPF, DKIM, Dmarc reports, antispam, webmail client, etc, is pretty high. The $5/user/month for Gsuite has been worth it for me, even though I could DIY if needed. Their UI makes all those things much smoother. Plus I get bonuses like their labs add-ons, etc.

One of the reasons to run your own mail server might be exactly the lack of desire to show your mail contents to a third party.

Do the people you send mail to and receive mail from also maintain their very own mail server?

It's a valid question.

They can as well use the same server, e.g. because they work for the same company / organization.

A different data retention policy and lack of third-party access may be very important in certain circumstances.

I agree that Exim doesn't seem to be a great choice, but:

> Don't run your own mail server. But if you have to, don't run a C-language mail server. But if you have to, run Postfix.

I... don't think Postfix' track record bears this out? Setting up a mailserver is quite a bit of work, but if you configure Postfix with an appropriate degree of paranoia and don't care about receiving some spam, you can leave Postfix running for years and years with zero vulnerabilities. (E.g. https://www.cvedetails.com/vulnerability-list/vendor_id-8450..., as you know.)

It's hard to compete against GMail's security, but if you have to run some service on your own Postfix is much less likely to get you pwned than almost any web application, or even many HTTP servers. (Postfix shares that distinction with another large-but-excellent C application, OpenSSH.)

(Mind you, "appropriate degree of paranoia" includes absolutely not running anything like a virus scanner, which protects your server but leaves your mail user agents open to attack.)

Postfix in its Debian default config state is pretty safe, but also doesn't do much. The danger comes when people who don't really understand smtp and Linux security start modifying its config files wildly.

The OpenBSD project has OpenSMTPD [1] which is way easier (and pleasant) to configure than Postfix and has been audited by Qualys [2] (in 2015, however). I would also consider that a solid choice.

[1] https://www.opensmtpd.org/

[2] https://www.qualys.com/2015/10/02/opensmtpd-audit-report.txt

I am actually kind of surprised it is th default Debian smtpd. First thing I do on any Debian server that needs to handle mail is rip it out and replace with a postfix configuration that I have been using for many years.

What are some reasonable SMTP servers written in languages other than C? Any recommendations?

I'm happy with my choice to replace exim with postfix on all my debian/ubuntu machines. This is not the first time an exim 0day has surfaced while I can't recall the last time there was a remote exploit for postfix.

I don't believe that this counts as a 0-day since the patch was created and released two to three weeks ago.

Timeline here:

* http://exim.org/static/doc/security/CVE-2018-6789.txt

The interesting entries:

> * 2018-02-09 One distro breaks the embargo

> * 2018-02-10 18:00 Grant public access to the our official git repo.

Since the report came in on the 5th there wasn't really a lot of time before the "distro" released it.

"Vulnerabilities found by Meh, DEVCORE research team." Any more details regarding how the flaw was found? I don't see an Exim entry in the AFL trophy case http://lcamtuf.coredump.cx/afl/ Also nothing about Exim on oss-fuzz.

Previous devcore article (https://devco.re/blog/2017/12/11/Exim-RCE-advisory-CVE-2017-... ) about another Exim bug mentions fuzzing. I suspect that is how this issue was found but I'd love more details if anyone knows anything.

Reply on news.ycombinator.com