Note: at least some of you know that I have used exim for quite a while
and am fond of it, so this is not meant as bashing.
I was speaking with some friends yesterday, and as I was talking about
exim one of them said exim was taking a fairly heavy beating in some
security-related forums (fora?). I asked for specifics and was sent the
following.
Is any of it worthy of comment? Undeneath the flamage, is there any shred
of a valid point being made here? It's dated in 1997; have its concerns
been dealt with? I have no desire to open old wounds if any exist.
Thanks.
- Evan
---------- Forwarded message ----------
| 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
| >by 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));
--
*** Exim information can be found at
http://www.exim.org/ ***
