Author: Phil Pennock Date: To: Marc Perkel CC: exim-users Subject: Re: [exim] 4.74 exim.conf has the wrong owner, group, or mode
On 31 Jan 2011, at 16:56, Marc Perkel wrote: > You're trying to force feature that not everyone wants. I think it's a
> bad idea. You can't assume that everyone is running in an environment
> like what you imagine. It just becomes a pain in the ass for those who
> don't want your artificial restrictions.
Mr Perkel,
The dent in the wall over ----> there? That is from my head. Please,
take pity upon the walls, and follow a simple rule:
When people who work hard to maintain backwards compatibility in a
product decide that it is worth breaking backwards compatibility,
spend some time thinking about _why_ they might have done so, instead
of assuming that they're stupid/uncaring/whatever.
Unix systems programming is predominantly done in C, a language which
leaves programmers prone to slips permitting remote code execution. Phil
Hazel did a *great* job with Exim, avoiding most of the pitfalls and
writing safe code. With Exim 4, he improved things further over Exim 3,
by dropping entire models of execution which had been proven unsafe.
But great as he is, Phil Hazel is not a god. It's a shock, but he's
imperfect. Further, the current maintainers are imperfect too. Tony
Finch appears to be striving for godhood in coding -- it must be
something about the University of Cambridge -- but I know that I make
mistakes.
Releases of Exim until 4.70 contained a remote code execution bug.
Someone in the blackhat community developed an exploit tool which would
exploit that to run code as the Exim run-time user, and then use a
design flaw in Exim to run code of their choosing as "root", thus
compromising a system. Because 4.69 and some other earlier releases
were still in widespread use, and the Maintainers did not call out
widely "hey, buffer overflow, you maintainers should backport this one",
a lot of systems in the "wild" were vulnerable long after we'd issued
releases which fixed the initial hole.
We are not gods. We should not assume we are perfect. The only safe
assumption is that somewhere else in Exim there is another remote code
execution flaw. A subtle one, to have remained hidden all this time,
but still there. The next time it happens, users of Exim should be
confident that the only impact was access to the Exim run-time user and
that they can be safe updating just Exim and will *not* need to
reinstall the operating system from trusted media.
Security of the systems of those who trust us by running code we
maintain is one of the very few reasons that we break backwards
compatibility. Those who wish to run insecurely are responsible for
maintaining the patches to Exim to do so.
Note that until recently the Exim docs strongly discouraged using "root"
as the run-time user for Exim, but it wasn't forbidden. Some people did
so anyway. We no longer support that, and likewise force those people
to maintain local patches. That actually went in *before* the exploit
was known, but was an easy argument to make -- we will not support
known-bad configurations of Exim.
If you insist on shooting yourself in the foot with a miniature tactical
nuke, we not only require you to disengage the safeties, we require you
to actively modify Exim to remove the built-in safeguards. You are free
to do so, this is open source, it's your system, modify it as you wish.
But if you do so, you're unsupported and when things break, it's
entirely your fault.
