[plug] This Mailing list

[Christian]

John Summerfield wrote:

> > Sendmail probably isn't as bad as most people make out, but at the same
> > time there would seem to be *some* validity to *some* of the claims
> > given they come up so frequently.  Perhaps most on this list wouldn't
> > gain very much by replacing it but, consider that many subscribers to
> > this list have little interest in spending too much time administering
> > their Linux machines; they'd much rather spend their time using them.
> > When the next sendmail security bug is discovered, if these people want
> > to keep their machines safe, they have no option but to subscribe to a
> 
> That is complete rubbish.

Of course it is.  Oops.  Silly me.

> If people want to keep their machines absolutely safe they won't connect
> to the Internet. Next best is to configure it to not allow connexions from
> outside to smtp, dns, ftp, http etc by configuring ipchains appropriately.

Not connecting to the Internet would definitely make delivery of mail
from this list much more difficult.  But you're right John, we should
all disconnect from the Internet in order that we can continue running
sendmail safely.  After all, what is the alternative??  A smaller,
faster, less-resource-consuming, secure, MTA like Postfix or qmail?  The
thought is too horrible to bear!  (I'm deliberately ignoring your
reference to ipchains since learning to use this would probably be
harder than configuring sendmail to listen only on the loopback or
internal interfaces so that seems a pointless proposition.  It's also
inconsistent with my suggestion above that many home users want to AVOID
administration tasks.)

> I'm on several watch lists; I don't recall a mention of sendmail. Red Hat
> software is pretty good with security-related updates but there have been
> no between-release updates of sendmail since Feb 1997 when sendmail 8.8.5
> was released for RHL 4.1.

You must be on the wrong lists.  Below are three *very recent* sendmail
vulnerabilities.  If you doubt their authenticity, have a look at
www.securityfocus.com which is where I got them from by doing a simple
search on the word "sendmail".

December 20th, 1999 (that's more recent than Feb 97, isn't it?)
================================================================
Remote user may exhaust system resources and potentially force a reboot.

December 7th, 1999
===================
Any local user can corrupt the aliases database.

November 5th, 1999
===================
Any local user can gain complete control over the mail server.

This doesn't include several vulnerabilities that merely used "features"
(often minor flaws) of sendmail to ease or facilitate exploitation. 
This includes several serious ones like the flawed Linux accept()
implementation (denial of service via a minor sendmail glitch) and the
Vixie cron MAILTO vulnerability (not sendmail's fault but it sure made
things easier: local root compromise).

As Leon has already indicated, sendmail's age has resulted in some
degree of "cruftiness".  Although sendmail's security record is
certainly looking better than it has been in the past, by the same
token, that isn't saying very much.  Designing a piece of software with
security in mind right from the beginning will lead to the software
being more secure -- even compared with software that has been around a
long while and has had time to "mature".  Both Dan Bernstein and Wietse
Venema have done this with qmail and Postfix respectively and IT SHOWS. 
If you want the ability to be able to rely on the security of software
then choose something that has been designed with security from the
ground up -- maturity simply does not count enough.

> I do note that bind (much more troublesome than sendmail) has a recent
> upgrade for 4.2:
>  ftp://sunsite.unc.edu/pub/Linux/distributions/redhat/updates/4.2/i386/bind
> -8.2.2_P3-0.4.2.i386.rpm

Yeah, BIND appears to be making a concerted effort at stealing the title
of "Worst Security in a Piece of Free Software" away from sendmail. 
However, the ISC has promised that BIND 9 will be a re-write from
scratch with security in mind.  I wonder when we'll see a similar
promise from sendmail?  And, if they do, I suspect you won't get it for
a long while to come since, after all, sendmail is now a commercial
product with 'sendmail pro' getting all the new features and the free
version of sendmail deliverately being lagged behind.  By the same
token, Dan Bernstein is developing 'dnscache' as a secure replacement to
BIND... his security record with qmail has been pretty impressive so
this is probably one to watch.

I apologise to all the people who have had to sit through *two* of these
arguments between John and myself in recent times.  The last one started
with me requesting for people's feedback and experiences on sendmail vs
qmail vs Postfix where I got corrected for suggesting that sendmail was
sometimes a resource hog and was told by John "don't change from
sendmail if you have a working configuration..."  No useful feedback
there (although Matt suggested smail which I was already familiar
with).  This most recent skirmish came out of me wondering if a change
in MTA had influenced an increase in list speed (I asked this purely
because I've noticed big differences between the latency of several
lists I'm on and was wondering what the factors were involved since I
had heard that sendmail was often at fault) and asking if anyone had any
experience/stats on performance under mailing list conditions of the
various MTAs.  The fact is, at the time of my first request for feedback
I had no strong feelings towards any MTA one way or the other.  I'd used
sendmail and smail (and was starting with Postfix) but was very
interested in other people's opinions.  Since that time I've started to
really like Postfix and would now recommend it to almost anyone.  I'm
still not sure about how well it performs under extreme stress so I'd
still like to hear from anyone who has experienced or tested it although
we'd better do it off list in case we upset someone.  I don't think I've
done anything wrong by requesting for other people's opinions and
feedback and I'm sorry if this upsets anyone's sensibilities on a
particular pet-program of theirs.  This is the last email I'll be
sending on this particular topic.

Regards,

Christian.

-- 
Perhaps I am flogging a straw herring in mid-stream, but in the light
of what is known about the ubiquity of security vulnerabilities, it
seems vastly too dangerous for university folks to run with their heads
in the sand.
						    - Peter G. Neumann