} Did anyone read the message posted to comp.security.unix that was attacking
} exim for its multiple vulnerabilities?
Here is the posted message - unedited by me
Nigel.
From: Re: Is Unix Security Really So Weak?
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));
[ Nigel.Metheringham@??? - Systems Software Engineer ]
[ Tel : +44 113 251 6012 Fax : +44 113 224 0003 ]
[ Friends don't let friends use sendmail! ]
