From owner-freebsd-security Mon Aug 26 02:42:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA00283 for security-outgoing; Mon, 26 Aug 1996 02:42:34 -0700 (PDT) Received: from freebsd.gaffaneys.com (dialup16.gaffaneys.com [134.129.252.35]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA00276 for ; Mon, 26 Aug 1996 02:42:29 -0700 (PDT) Received: (from zach@localhost) by freebsd.gaffaneys.com (8.7.5/8.7.3) id EAA01803; Mon, 26 Aug 1996 04:42:53 -0500 (CDT) To: Gene Stark Cc: security@freebsd.org Subject: Re: Vulnerability in the Xt library (fwd) References: <4vqqpl$bn8@starkhome.cs.sunysb.edu> <199608260330.XAA12903@starkhome.cs.sunysb.edu> From: Zach Heilig Date: 26 Aug 1996 04:42:52 -0500 In-Reply-To: Gene Stark's message of Sun, 25 Aug 1996 23:30:42 -0400 (EDT) Message-ID: <87hgpqo50j.fsf@freebsd.gaffaneys.com> Lines: 39 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gene Stark writes: > This is the worst one yet for me. A crazy idea occurred to me, what do > other people think? Why not nip all this stuff in the bud by changing the > semantics of exec() so that setuid privilege is turned off unless the > program has previously executed a (new) system call that says "I really > want setuid privileges to be passed to my children." Of course, this > would be nonstandard, but it would have the nice property that since no > existing program calls this system call (it doesn't exist yet) no further > exploits of this type would be possible with existing software. > Calls to this new system call could then be introduced carefully into > existing software, right at the point where an exec that *has* to preserve > setuid privilege is performed. > > I would hazard a guess (flame me if I'm wrong) that most setuid programs > don't need to exec other stuff, so this type of change would not break > as many things as you might think at first. Well, all the attacker has to do is add a call to that system call just before the code that exec()'s the shell. All this does is add an extra step for the attacker to maybe stumble on. Besides, what would the semantics be if all the userid's were 0, as in the case of some daemons with this sort of vulnerability. I don't think this would really solve the problem. What we need is a lint-like utility (better than gcc) that can warn when it finds code like: { int buf[somesize]; strcpy(buf, argv[1]); } which is dangerous in all programs, it's just less dangerous than in setuid ones. -- Zach Heilig (zach@blizzard.gaffaneys.com) | ALL unsolicited commercial email Support bacteria -- it's the | is unwelcome. I avoid dealing only culture some people have! | with companies that email ads.