Bugtraq mailing list archives
Re: libresolv+ bug
From: dholland () hcs harvard edu (David Holland)
Date: Thu, 22 Aug 1996 18:13:21 -0400
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
Current thread:
- Re: libresolv+ bug, (continued)
- Re: libresolv+ bug Jon Lewis (Aug 20)
- SigSev -> Security Hole Tim Smithers (Aug 20)
- Re: SigSev -> Security Hole Brian Mitchell (Aug 20)
- Re: libresolv+ bug Don Lewis (Aug 20)
- Re: libresolv+ bug Zygo Blaxell (Aug 21)
- Re: libresolv+ bug Zygo Blaxell (Aug 21)
- Re: libresolv+ bug Julian Assange (Aug 21)
- Re: libresolv+ bug Thomas Ptacek (Aug 21)
- Re: libresolv+ bug Nick Andrew (Aug 22)
- Re: libresolv+ bug John Macdonald (Aug 22)
- Re: libresolv+ bug David Holland (Aug 22)
- Re: libresolv+ bug Zygo Blaxell (Aug 22)
- Re: libresolv+ bug Mikolaj J. Habryn (Aug 23)