Re: ncurses 4.1 security bug

[imp () VILLAGE ORG (Warner Losh)]

In message <9807091617.ZM3971 () nocboy ntr net> Matt Evans writes:
: a.jar() and b.jar() are going to both get called before other_stuff(),
: but you have no way of knowing in which order a.jar() b.jar() get called with
: respect to each other.  does jar() need to drop privs ?  i hardly think so.
: what happens when "class lazy_programmer{};" comes along ?  must all of its
: constructors also "drop privs" as well ?  if every function "drops privs"
: before main() ever starts, and every function does so in some random order, i
: fail to see how you can create a useful set[ug]id program.

And you have no way of knowing if they get called in such a ways as to
put libc at risk.

I see two solutions to this problem:

        1) set?id programs need to be modified.  They need to come up
           with their privs disabled and explicitly enable them for
           the work they need to do.  This is definitely a change in
           the traditional behavior of how set?id works.  It would buy
           a few things at the cost of a few other things.  I'm
           surprised that I've need seen references to this in the
           literature.

           The up side is that chmod 4777 /bin/sh no longer gives you
           a setuid shell.  Code would have to be more explicit in its
           use of privs.  This is likely a good thing.

           The down side is that chmod 4777 /bin/sh no longer gives
           you a root sheel.  ALL setuid programs must be changed to
           run on a system like this, or they will fail to operate.

           This would fix the class of problems that are characterized
           by code running with too many privs to access shared
           resources.  This seems like an interesting enough set of
           problems to go after.

           I suspect that you don't want to do this in crt0.o because
           a roughe program could easily bypass that check.  Kernel
           support seems a must.

           Doesn't do squat about the problem of buffer overflows...

        2) have an option to ld that refuses to allow any global ctors
           to be called.  This way you could have some safety in the
           writing set[gu]id programs that are written in languages
           that allow this, or call library routines that allow this.

Comments?

Warner