[7227] in bugtraq
Re: ncurses 4.1 security bug
daemon@ATHENA.MIT.EDU (Warner Losh)
Sat Jul 11 17:24:51 1998
Date: Fri, 10 Jul 1998 14:07:54 -0600
Reply-To: Warner Losh <imp@VILLAGE.ORG>
From: Warner Losh <imp@VILLAGE.ORG>
X-To: Matt Evans <bmajik@NOCBOY.NTR.NET>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Thu, 09 Jul 1998 16:17:25 EDT."
<9807091617.ZM3971@nocboy.ntr.net>
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
