

Remote root access vulnerability in exim - rapid action advised - samstokes
https://forum.bytemark.co.uk/comments.php?DiscussionID=2701

======
tptacek
Can I in the strongest possible terms recommend that you _not run_ Exim, and
instead migrate posthaste to Postfix or qmail?

Exim is lumped in with Postfix and qmail as one of the "next-gen" MTAs written
in response to the 1990s Sendmail security debacle. But it's really not; Exim
is a last-gen design very closely reminiscent of SMail, which is basically
Sendmail but with far less security attention.

It has been a constant annoyance going on 15 years for me now to see people
recommending Exim as a secure alternative to Sendmail. It may be many good
things, but high-assurance software is not one of them. In 2010, who has time
to worry about whether their mail server is handing their internal network
over to attackers?

Not for nothing, but, a silent patch to a remote code execution flaw (from
2008!) is a major breach. You want an example of the kinds of things that turn
vulnerability researchers into raving assholes: there's a good one right
there.

~~~
AlexMax
I'm curious why you would recommend qmail these days. The last official
version was released in 1998, and it seemed like it was stuck in some weird
licence limbo until 2007, making forks unable to be distributed with linux
distributions.

~~~
tptacek
I trust qmail more than I trust Postfix. I may be biased; I found a
vulnerability in Postfix early on. qmail has one of the best security track
records of any piece of Internet software ever written; so far as I know, the
only bona fide major vulnerability ever found in qmail required a nonstandard
64 bit deployment, and an attacker writing gigabytes of data to the server.

I think you kind of have to admire a piece of software that is still useful
without changes more than a decade after it was released. You're entitled to
think differently.

The license stuff is totally irrelevant to me. Bernstein didn't want his code
forked ("incompatibility is a bug"). Hordes of Linux people, most of whom had
never published a line of C in their lives, swarmed him and the Internet with
complaints about how qmail wasn't open source or (worse, and more
misleadingly) was "proprietary".

It's public domain now.

Postfix is a perfectly acceptable alternative to qmail.

~~~
JoachimSchipper
Didn't qmail's license require you to install it in /service/qmail or
something similarly nonstandard? I admit that it _might_ be better if things
_did_ work that way, but they don't and having one program work differently is
just annoying.

Of course, this is not a problem now that it's unambiguously public domain.

~~~
jrockway
The license didn't require you to do that. It required Linux distributors to
install it there by default.

------
dpifke
More information about the vulnerability (which was fixed over a year ago) can
be found here:

[http://www.exim.org/lurker/message/20101210.164935.385e04d0....](http://www.exim.org/lurker/message/20101210.164935.385e04d0.en.html)

~~~
tptacek
In December, 2008, the Exim team accepted a bug fix for "memory corruption in
string_format code", noting "string_format() will happily overwrite beyond
allocated memory"; the CVS commit message was "Buffer overrun fix. fixes: bug
#787".

Apparently, nobody thought this was worth alarming end-users over.

<http://bugs.exim.org/show_bug.cgi?id=787>

------
tedunangst
"You're safe if any of the following is true: ... The build date is Friday
10th December 2010 or later; "

I find it hard to believe that simply recompiling old broken code will
magically fix it.

~~~
samstokes
Without knowing more, I'd guess that means they rebuilt the binary against a
new version of some library.

~~~
tedunangst
The build date still doesn't indicate what libraries it links with.

------
xd
If you are running exim on localhost for outbound mail only you shouldn't need
to panic (like I just did) :D

