Bugtraq mailing list archives

Re: UnixWare


From: mouse () collatz mcrcim mcgill edu (der Mouse)
Date: Wed, 27 Apr 1994 15:14:31 -0400


Personally, I can think of all sorts of security flaws at the kernel
level that have NOTHING to do with setuid programs.
Name a couple for us then.

I'm not the person who posted the text you're challenging, but....

Item: I don't know of any system that behaves completely correctly with
respect to disconnecting programs from pseudo-ttys when they (the ptys)
get closed.  Many of the older systems still in use at smaller sites
are positively dismal here.

Item: Many older systems, and at least one quite recent Ultrix version,
are vulnerable to a denial-of-service attack that is often duplicated
without malicious intent by firewalls: on receiving a single host
unreachable, they summarily shut down all connections to that host;
some may also do this for net unreachables, but I don't know.

Item: NFS has numerous security flaws (as anyone who's been following
this list recently knows!), some of which cannot be fixed because
they're design bugs, and most systems supporting NFS have it in the
kernel.

Find me a few days of spare time to go reacquaint myself with kernels
and I could probably name you a couple more.

Virtually every alert is related to a program thats setuid root, or
that is needlessly running with root privileges (like sendmail).
(And then, I can also think of a few associated with programs that
CAN'T be run non-setuid).
Many programs cannot be run non-setuid.  Few functions, however,
cannot be accomplished entirely with non-suid programs.

Not to claim that there aren't too many suid-root programs around; on
that point I agree with you - but this claim of yours strikes me as
unreasonably strong, unless you're proposing to rework large fractions
of the system.  For example, utmp writers could be changed from suid
root to sgid utmp...until you find one that needs to perform some other
function that you've moved from suid-root to a group of its own (kmem,
for example, or tty).  All these could be fixed by redesigning the
mechanisms in question - the way utmp is maintained, for example - and
reimplementing all the relevant programs with the new paradigm.  Where
do you draw the line between fixing a program and redesigning the
system?

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu



Current thread: