[3258] in bugtraq
Re: libresolv+ bug
daemon@ATHENA.MIT.EDU (David Holland)
Thu Aug 22 21:34:35 1996
Date: Thu, 22 Aug 1996 18:13:21 -0400
Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
From: David Holland <dholland@hcs.harvard.edu>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <199608221256.WAA32109@godzilla.zeta.org.au> from "Nick Andrew"
at Aug 22, 96 10:56:57 pm
> > The primary problem, as I see it, is not that SUID programs are being
> > written poorly, or that the sensitivity of SUID programs is not being
> > adequately dealt with by the operating system, or the compilers that
> > produce the executable code; it's that SUID programs, as present in most
> > modern Unix operating systems, are being written at all.
Yes, exactly.
(The original message then went on to talk about POSIX.6 privilege
masks and such which still involve execution at higher privilege
levels, even if they aren't precisely setuid. These solve nothing and
are at best a band-aid.)
> The problems are orthogonal. Poorly written programs can still be
> exploited through buffer overflows, stack corruption and the like.
> The only difference is - if the program has no additional privileges
> then the program can do nothing which the intruder couldn't do anyway.
Exactly. [Various other good points deleted]
Now, the problem is, one is almost always going to have to have
programs that perform privileged operations on behalf of ordinary
users. One is always going to have network services that perform
privileged operations on behalf of totally unprivileged outsiders.
Whether this is done by setuid execution or proxy execution of some
sort by a daemon is in some ways irrelevant. (Although proxy execution
is a good bit safer.)
Splitting root privileges up into a bit vector is not especially
worthwhile if one can use some privilege bits to acquire others. In
general, for the things root can do, a compromise of one privilege bit
is going to lead directly to compromises of most of the others.
For example, if you can get the permission bit that lets you write to
raw disk devices, you can have any other permission bit you like by
tampering with the filesystem. It may be somewhat difficult, but
that's security by obscurity.
This is like how it's trivial to get root once you've broken into
"bin" or "lp" on most systems.
I think the first step to take is to look at every setuid program (and
possibly setgid programs too) and figure out how to implement it
without using any setuid or enhanced privilege features.
Only once the system is free of setuidness entirely is it particularly
to start looking at splitting privilege levels. Many of the things
that once would have needed privilege won't any more.
It is also a mistake to examine only root privileges for a privilege
bit vector. Such privileges as "connect a socket" should be included
as well. Ideally, with all the bits in the privilege vector clear
you'd be willing to run thoroughly untrusted binary code anonymously
mailed to you.
The POSIX.6 privilege bits spec (which is a codification of the
schemes used for DOD B* security by various vendors) does not address
these issues at all, and it is probably a mistake to use it as a model
for any new design.
> I think it protects the filesystem - or rather, it protects against
> filesystem-based attacks. No such protection against code subversion.
Arguably, using the same stack for automatic variables and return
addresses is a design mistake.
--
- David A. Holland | Number of words in the English language that
dholland@hcs.harvard.edu | exist because of typos or misreadings: 381
