Re: default MTA for sarge
On Wed, 16 Jul 2003 10:58, Craig Sanders wrote:
> correction: i said exim's *design* is insecure.
>
>
> AFAIK, there are no current security holes or exploits for exim. there
> have been in the past, and the insecure design means that there probably
> will be in future.
Correct.
I believe that Exim uses the same basic design as Sendmail, a single
executable is used for the daemon (which does all spooling and delivery
actions, spawning Procmail, writing files directly to home directories,
reading ~/.forward, etc) and for sending mail locally "sendmail -t".
This means that if there is a bug in one part of the daemon's operations it is
likely that it will be able to get full access to the user's home
directories. Postfix and Qmail have a number of small programs running as
non-root which do a small number of well defined tasks. This means that if
one of those programs has a bug triggered by a buffer overflow it must then
be tricked into exploiting the next program in the chain before access to the
user home directories is gained. This means that exploiting a mail server is
not a simple matter of finding a single bug, but a long and arduous process.
Finally if using a modified Linux kernel for extra security such as Security
Enhanced Linux you have better control over Postfix or Qmail than Sendmail or
Exim.
With Sendmail/Exim you have one binary used for sending mail (called from
mailx etc) as well as for the daemon. So when a system boot script runs it
the kernel is unable to determine if it was called from a daemon that wants
to send email from it's boot script (a few of them do) or if it's the daemon
being started. Therefore the process spawned by mailx during system boot
gets the same access to the mail spool as the daemon does. This may not seem
like a problem, but consider the game exploit (for nethack if I recall
correctly) whereby a bug in the SETGID game allowed writing corrupt data to
the game files which then triggered a buffer overflow in a root process run
from the startup scripts. On a non-SE system such an exploit is devastating,
on a SE Linux system it gives limited ability to do damage unless something
else is weak.
My SE Linux policy for Postfix and Qmail has different domains for each of the
common daemon processes, this gives them greater isolation from each other
and the rest of the system than they normally get. For example only two of
the Postfix daemon processes are permitted to run procmail. If there was a
hypothetical known bug in procmail then you would have to get the Postfix
local delivery program or the Postfix "pipe" program to run Procmail if you
wanted to remotely exploit a machine, if it was not possible to get either of
those two programs to run Procmail in the manner required to exploit the bug
then a remote attack would be impossible. For Exim or Sendmail it is not
possible to restrict the access that part of the mail server has to Procmail.
Finally, some people who are more paranoid than me consider that it's bad
practise to put extra functionality in a program, any extra code is code that
can be potentially jumped to as part of a stack-smashing attack and used to
do undesired things. Based on this logic alone it is a bad idea to have the
local mail queuing functionality in the same binary as the mail server
daemon.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: