
Exim Off-By-one RCE: Exploiting CVE-2018-6789 with Fully Mitigations Bypassing - pjmlp
https://devco.re/blog/2018/03/06/exim-off-by-one-RCE-exploiting-CVE-2018-6789-en/
======
tptacek
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.

~~~
jamiesonbecker
> 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..)

~~~
tyingq
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.

~~~
nine_k
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.

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

~~~
nine_k
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.

------
0x0
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.

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

~~~
upofadown
Timeline here:

* [http://exim.org/static/doc/security/CVE-2018-6789.txt](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.

------
rripken
"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/](http://lcamtuf.coredump.cx/afl/) Also
nothing about Exim on oss-fuzz.

~~~
rripken
Previous devcore article ([https://devco.re/blog/2017/12/11/Exim-RCE-advisory-
CVE-2017-...](https://devco.re/blog/2017/12/11/Exim-RCE-advisory-
CVE-2017-16943-en/) ) 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.

