On Tue, Dec 22, 1998 at 08:45:36PM -0000, Scott Ballantyne wrote:
> > The conditions necessary to eliminate sendmail from hundreds of
> > thousands of computers have been laid out. Redhat *wants* to ship
> > qmail, but they need those conditions satisfied. Are you suggesting
> > that there is no compromise worth ridding the world of hundreds of
> > thousands of security disasters?
> >
>
> A nice compromise would be for Redhat to figure out how to do what it
> wants, since it *wants* to ship qmail.
As far as code goesRedhat does know how to make the changes they want.
As far as legalities, the copyright that dan puts on qmail prevents
them from distributing what they want to do.
> > It is entirely Dan's failure to act that has caused hundreds of
> > thousands of *new* copies of sendmail to be installed. I don't think
> > hysteria is a sufficiently extreme reaction.
>
> Let's see. this endless argument seems to be hammering home that
> Redhat feels that Sendmail + RPM is more secure than qmail without
> RPM.
No. Redhat feels that they can distribute sendmail as a packaged
binary without being open to being sued for violating dan's copyright.
For the heck of it, lets play out a scenario. It is similar to some
that I've seen.
First please briefly suspend disbelief, to make this a more sinister
scenario. Let's imagine that there is a root exploit hidden deep in
qmail. I don't know of one, I don't think anyone does, but since the
possiblity is always there, let's work with it.
Let's also say there is an rpm that was binary distributeable and it
modified its uids safely and all that nice stuff, and you use a
mini-qmail installation and a few qmqp servers in a lab of 150
workstations running redhat linux, solaris x86 and sparc - a couple of
versions as time has gone on, and sgi's. Since rpm works on all of
these platforms, you've started using it to package all of your
packages instead of a different package system for each (however, you
could also use the debian package manager in this sort of situation,
dpkg, and possibly others). You use rpm to customize all of the
tools, scripts, and programs that you use. Everything is the way you
want to aon all of these systems. You've got all of your build
scripts all nice and tidy your own diffs for the site.
One day, joe schmuck breaks into one of your solaris systems (was it
remote? was it one of the lab users? No, it's qmail!), starts
sniffing packets, doing other nice break-in things, and before you
know it some portion of your workstations are comprimised. You shut
down the lab, and proceed to determine what the attack was, and how it
was hidden, etc.
So, since you use rpm, you start by checking all of the recorded
md5sums for the packages you've installed against the master database
you have locked away on a day 1 backup tape. What's this! On every
system, the qmail binaries are different! Are they trojan'd? Or have
they just been modified by the installer you wrote so that
already-used uid's aren't clobbered. You don't know. Let's imagine
that you had a sadistic hacker, and they *did* modify the qmail
binaries(maybe qmail-send, maybe qmail-rspawn... you can't know!) in a
way that they mostly worked, the size was the same, but... it's a
trojan!
You can't rely on the checksum of a single one of those binaries being
accurate since a fair portion of them have been modified post-install
anyway. You can't track down how the attack progressed, or through
which systems. Boom. A tampered qmail killed your network, and your
week. This could have been prevented by having an unchanged binary,
and if qmail read its uids from a file all you'd have to do is use sed
and grep to confirm that the qmail id's in /var/qmail/control/ids (or
whatever) match what's in /etc/passwd. Using rpm you could have at
least saved the work of the linux systems.
In this case, sendmail, with the same exploit, could have left the lab
more secure, and gotten it back up in less time.
-Peter
