Bugtraq mailing list archives
Re: libresolv+ bug
From: tqbf () rdist org (Thomas Ptacek)
Date: Thu, 22 Aug 1996 00:21:50 -0500
Hardware-protected memory on both ends of every buffer and between the return address on a stack frame and the current function's automatic variables would be good for security purposes. That way most simple
[ much, much detail omitted ] All very good, interesting, thoughtful solutions, and I appreciate the information, but it doesn't address the point I'm bringing up. 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. You'd figure that at this point, we'd realize that one of the primary security issues we're dealing with is that Unix operating systems overload UID 0 hideously, in most cases opting to give any program that needs anything beyond normal user privileges full root access. Beyond that, no Unix OS I know of allows admins or programmers to reliably specify privileges in anything more than an "all or none" fashion - if your program needs permissions to write to /etc/passwd, you need to let it run /bin/sh and write to /root/.rhosts as well. I think it's been adequately demonstrated to us that the POSIX saved credentials solution insufficiently addresses the potential for subversion most SUID programs have. Instead of talking all day about how we should prevent security problems by patching individual security holes, both entirely and, on a program-by-program basis, piecemeal, as those holes are revealed to us, we should be discussing how to provide programs with enough privileges to do their job, and nothing more. Unfortunately, none of the solutions we've got out-of-the-box and on the net address "least privilege" adequately. It seems to me that this is an easier (and more worthwhile) problem to solve than "how we can best align memory to force buffer overflows to cause memory faults", which, although a very worthwhile issue in and of itself (which would probably save lots of programmers a lot of grief in the debugging process, as well as enhance security), doesn't do enough to address the broad range of problems that exist in SUID and daemonic programs. Regardless, I'll spare the readership of this list another holy war, and agree that you've got good points. Some of us have some tricks up our sleeve that we'll key y'all into when we've got the wrinkles ironed out, but I'd just like to toss the idea out to you that there's a pretty strong chance that we don't yet know everything we can subvert in an SUID program, and that resolving buffer overflow problems (as we know them) is really just one more band-aid on an inadequately expressive security system. [ as an aside... ]
1. A general-purpose setuid program that acts as a switching point for
[ elided ]
2. An interface script written in a language that handles its own memory allocation, like perl, or even GNU flavors of sed and awk; tcl would
Something to consider: I'm guessing that the reason everyone didn't instantaneously know about the 'suidperl' program, the minute that the program was brought into the afflicted operating systems, is that none of the people that normally run through source code finding bugs wanted to read 'perl'. The idea of allowing an interpreter for a language like perl (which I like, don't get me wrong...), swiss-army chainsaw that it is, to run with privilege, given the size and complexity and potential for weird interactions with that code, scares me greatly. It'll never happen on an operating system that I run, and I know that at least a few people out there agree with me. [ as another aside, which more directly supports my first point... ]
- binding to privileged ports (call bind(), drop privileges, exec child; inndstart does this with innd)
Bad! We're talking about problems (in this specific instance) in free, open operating systems, in which anyone can go tinker around in the kernel and fix whatever it is that concerns them. Why would you continue forcing programs to run as root, just so they can do something as trivial as binding to a privileged port (the concept of privileged ports strikes me as one of the worst concepts ever introduced into Unix networking code), instead of hacking your kernel so that some other UID or GID can do it instead (say, anything running as UID "netpriv" or GID "network"), thus eliminating any real concerns of far-reaching security programs in a whole ugly host of user-level networking programs? ----------------------------------------------------------------------------- Tom Ptacek at The rdist Organization / exit(main(kfp->kargc, argv, environ)); ------------------------------------------------[ tqbf () rdist org ]----------- "If you're so special, why aren't you dead?"
Current thread:
- Re: libresolv+ bug, (continued)
- Re: libresolv+ bug Jon Lewis (Aug 20)
- Re: libresolv+ bug Elliot Lee (Aug 20)
- Re: libresolv+ bug Nick Andrew (Aug 20)
- 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 Jon Lewis (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)