From owner-freebsd-security Sun Nov 17 18:48:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA03158 for security-outgoing; Sun, 17 Nov 1996 18:48:57 -0800 (PST) Received: from offensive.communica.com.au (offensive-eth1.adl.communica.com.au [192.82.222.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA03143 for ; Sun, 17 Nov 1996 18:48:53 -0800 (PST) Received: from communica.com.au (frenzy.communica.com.au [192.82.222.65]) by offensive.communica.com.au (8.7.6/8.7.3) with SMTP id NAA13142; Mon, 18 Nov 1996 13:17:45 +1030 (CST) Received: by communica.com.au (4.1/SMI-4.1) id AA15359; Mon, 18 Nov 96 13:17:22 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9611180247.AA15359@communica.com.au> Subject: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2). To: batie@agora.rdrop.com (Alan Batie) Date: Mon, 18 Nov 1996 13:17:21 +1030 (CST) Cc: imp@village.org, adam@homeport.org, pgiffuni@fps.biblos.unal.edu.co, freebsd-security@freebsd.org In-Reply-To: from "Alan Batie" at Nov 17, 96 05:16:36 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Alan Batie wrote: > > Sendmail is well understood and well maintained with a very long track > > record. Other mailers, no matter how much better, don't match this > > track record. > > Yup, sendmail has a long track record of the "security hole of the month"; > I've yet to see one for smail. I would like to switch to sendmail, as I > hear it deals with mail queues a lot better these days, and smail > development seems to have gone into a black hole, but until sendmail can > make it a whole month or two without a CERT advisory on it... Of course, one of the main reasons why sendmail is so "dangerous" is that despite fifteen years of it-hurts-when-I-do-this style experience, we *still* run it as root! Why do we do this? Why does nobody understand that a UNIX process can't just gratuitously gain privileges unless some other privileged program gives them away? Given sendmail's history, why do so many people still trust it with root privileges when it doesn't actually need them?! sendmail really only needs root so that it can bind to the "privileged" port 25 when it's running in daemon mode. If you frob filesystem permissions sufficiently you can get away without providing sendmail with root privileges by running it with a non-root uid out of inetd (which is, indeed, precisely what I have done with it here at Communica, where sendmail runs as the unprivileged "smtp" user). Tradeoff: High-volume sites will not like the fact that it doesn't run as a daemon, because it has extra overhead associated with fork()/exec() from inetd. On the other hand, the fact that it a) isn't running as a daemon here; and b) wouldn't have any scary privileges if it did has given me a warm fuzzy glow in the context of the latest bug. - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au