Hello,
>
> Both Dan Bernstein and Thomas Ptacek are abrasive characters, but have
> a track record in security and deserve to be listened to (you need to
> filter out the attitude, though). The latter was particularly critical
> of bounds checking in exim, and believed that numerous buffer overflow
> exploits were probably possible. Of course, this was more than 3 years
> ago, and the code has moved on since then.
Actually I tried to tracking this article, and when I ran a web search
using google.com I found it on the exim.org site itself!
http://www.exim.org/pipermail/exim-users/Week-of-Mon-19980914/009154.html
| 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));
I have read somewhere that DJ barnstein is indeed prone to temper
outbursts as this poster sugegsts, but since he is the authour of qmail I
suppose he knows what he is talking about when he mentions security.
> > That strikes me as peculiar behavior. Many people switched from sendmail
> > to exim because of security issues among others. But it appears that in
> > the qmail circles there is a wide spread belief of security problems with
> > exim. I suspect that that is mostly rumour based on very out-of-date
> > inuendo and some hype. But like most such things, there is often some
> > grain of something somewhere that should be looked at. I'm sure that
> > people here will look at it in good faith.
>
> An in-depth and independent security audit of exim would be a Good
> Thing.
Actually the original URL which one of my collegues referred me is
http://starbase.neosoft.com/~claird/comp.mail.misc/MTA_comparison.html
Which compares several MTA's including exim.
It says about exim,
"Among exim's assets are its documentation, generally responsive and
courteous (lead?) developer Philip Hazel, and active mailing list. On the
other hand, exim is not a particular leader in regard to security.
Several people have told me exim's configuration is "easy", in contrast to
that of, say, Zmailer, or qmail. "
Since I had already had sufficient interest in Exim, I posted here to
clarify this from people at the exim.org itself.
Mustapha Mahfouz
