I found the following msg in the fwtk-users mailing-list. Any comments
from exim-gurus?
---------- Forwarded message ----------
Date: Fri, 11 Sep 1998 12:53:35 +0200 (MET DST)
From: Eberhard Mattes <mattes@???>
To: fwtk-users@???
Subject: Re: simple sendmail replacement?
[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to majordomo@???.]
> And what about exim? Any comments?
Here's a Usenet post on this topic:
| From: tqbf@??? (Thomas H. Ptacek)
| Newsgroups: comp.security.unix,comp.unix.admin,comp.unix.question,comp.unix.solaris
| Subject: Exim? Secure? Uh...
| Date: 15 Apr 1997 00:11:22 GMT
| Organization: EnterAct, L.L.C.
| Lines: 82
| Distribution: inet
| Reply-To: tqbf@???
|
| 12 Apr 1997 10:02:54 GMT nmm1@???:
| >That is complete nonsense. I have not looked very hard at any of them,
| >but I did take a fairly close look at Exim following the last diatribe
| >but a qmail camp follower. The claims about Exim's insecurity were
| >firmly grounded in prejudice.
|
| I suggest you look harder next time, and give a closer look at Sendmail
| before standing up and proclaiming that Exim is wildly different from it.
|
| Exim is a monolithic program that performs various MTA-related tasks by
| looking at argv[0]. It configurably runs as root, "semi-root", or
| non-root, in the same manner as Sendmail: it loses significant
| capabilities running with all privilege discarded, but in normal operation
| uses seteuid() to "temporarily" discard privileges.
|
| As stated continuously on this newsgroup, with respect to many security
| issues, seteuid() does absolutely nothing to protect against code problems
| that allow an attacker to entirely comprimise the running program. An
| attack allowing me to execute arbitrary system calls in this environment
| allows me to simply reset my credentials back to root.
|
| Exim seems to exhibit all the security design mistakes Sendmail has made,
| only Exim handles them even more poorly than Mr. Allman does - at least
| Sendmail has a platform-independant snprintf() routine (Exim relies on
| sprintf and vsprintf throughout the code). In fact, if the authors of Exim
| had paid attention to Sendmail's progress at all, the code would be many
| times more secure.
|
| Specific examples include giving little (or no) consideration to the
| size of data read from the environment, arguments, or the outside world,
| string manipulation and logging routines which hide unchecked standard C
| library string copy and formatting operations (I'm particularly fond of
| string_sprintf), and, in some situations, even trusting argv[0] as passed
| to the program to contain the path to the exim binary.
|
| I've taken only a cursory look at Exim (in fact, I haven't even strayed
| out of "exim.c" yet). I do not claim to fully comprehend all the security
| implications of the code. However, what I have seen thus far is frightful;
| for instance, have a glance at "debug_printf()" - a varargs routine that
| hides an unchecked string format into a 256 character stack buffer. This
| routine is called 381 times from within Exim, in all parts of the code.
|
| There are points in Exim's code where textbook stack overruns are as
| simple as passing overly-long command line arguments - and, amusingly
| enough, the code is protected not by a bounds check, or even the
| Sendmail allocate-then-copy idiom, but by POSIX argument length limits!
|
| Moreover, Exim's "security consciousness" is defined by a variable living
| in Exim's process memory space. For that matter, so is the binary Exim
| executes when restarting itself (defined by a global pointer called
| "exim_path"). What's to prevent someone from altering either of these
| and subverting the program? Certainly not the code!
|
| These are silly little observations that I (and anyone else who
| understands basic C programming) am capable of making at a glance. I
| haven't even bothered to look yet at how Exim handles temporary files (and
| file manipulation in general). I'm a long way from spotting any subtle
| problems in the package, and I'm already fairly certain that obtaining
| root (or exim_uid) from it is more a matter of time than skill.
|
| I recognize that, at this point, many people follow qmail like a religion.
| This is because qmail is well designed, fast, and has a documented
| security design that makes sense and addresses the major security issues
| that have been highlighted in the past few years (primarily in Sendmail's
| RELEASE_NOTES). By way of comparison, Exim not only doesn't document
| secure design, but also seems to have ignored almost everything that has
| contributed to the insecurity of Sendmail.
|
| So, my prejudice, at this point, would be more against "programs that work
| like old versions of Sendmail" than against "programs that work
| differently from qmail". At this point, I'd be far more comfortable
| running Sendmail 8.8.5 on a sensitive machine that I would be running any
| revision of Exim.
|
| --
| ----------------
| Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@???]
| ----------------
| exit(main(kfp->kargc, argv, environ));
--
Eberhard Mattes <mattes@???>
--
-----------------------------------------------------------------------
Rudolf Kompf | E-mail: kompf@???
--
*** Exim information can be found at
http://www.exim.org/ ***
