On Tue, 29 Aug 2000, Mustapha Mahfouz wrote:
> Hello,
> http://www.exim.org/pipermail/exim-users/Week-of-Mon-19980914/009154.html
You will probably find follow-ups to the article there as well.
> | From: tqbf@??? (Thomas H. Ptacek)
> | Exim is a monolithic program that performs various MTA-related tasks by
> | looking at argv[0].
I am not convinced that that is a design problem.
> | 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.
That is not entirely true. Exim processes *permanently* discard
privileges, if I understand correctly.
> | 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.
Again, see above. I simply don't believe that that is true, but I am not
an expert on such things.
> | Exim seems to exhibit all the security design mistakes Sendmail has
> made,
That is a contentless statement.
> | 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.
For years now exim has used its own sprintf() functions. Though I am a
bit surprised that PH made the mistake of using the standard library one
in the very early days of exim.
> | 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.
All of that has been long fixed I believe.
> | 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.
Because this buffer overflow issues were isolated in a few routines, they
were easy to fix.
> | 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!
I really think that all of the buffer overflow issues have been addressed,
so to speak, a long time ago.
> | 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!
This is interesting. Anyone who knows more about these things wish to
elaborate? I'm not sure what the alternative is recommended.
> | 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.
That is a pretty damning comment. But it is three years old. At least
now I know why people in the qmail community say such things about exim.
In another posting you asked what major sites use exim. It is extremely
popular in the UK, where it may move more mail around the internet than
any other MTA (I haven't seen the latest poll results). It is used by the
leading ISPs (freeserve, demon) in the UK and some big ones in Germany.
It is extremely popular among UK universities.
> 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.
Any serious security critique should be looked at. The bulk of the above
is about buffer overflow problems. I belieive that they have all been
addressed.
> Actually the original URL which one of my collegues referred me is
> http://starbase.neosoft.com/~claird/comp.mail.misc/MTA_comparison.html
Thanks for that. Unfortunately the deja links from that don't seem to
work.
> 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.
Again, I expect that that is a repetation based on the earlier buffer
overflow points.
> Several people have told me exim's configuration is "easy", in contrast to
> that of, say, Zmailer, or qmail. "
Having never used those, I can't say. It is in my experience easier than
sendmail (well that is not saying much), easier than PP, easier than MMDF.
> Since I had already had sufficient interest in Exim, I posted here to
> clarify this from people at the exim.org itself.
Philip Hazel is away for a few weeks. He probably could have given a more
useful response. Good luck in sorting things out.
In addition to exim, you may wish to take a look at postfix which I have
heard good things about.
-j
--
Jeffrey Goldberg
I have recently moved, see
http://www.goldmark.org/jeff/contact.html
Relativism is the triumph of authority over truth, convention over justice
