From owner-freebsd-security  Sun Aug 25 23:02:20 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id XAA19727
          for security-outgoing; Sun, 25 Aug 1996 23:02:20 -0700 (PDT)
Received: from bsd7.cs.sunysb.edu (bsd7.cs.sunysb.edu [130.245.1.197])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA19720
          for <security@freebsd.org>; Sun, 25 Aug 1996 23:02:14 -0700 (PDT)
Received: (from uucp@localhost) by bsd7.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id CAA14430; Mon, 26 Aug 1996 02:02:09 -0400
Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.7.5/8.6.9) id BAA13245; Mon, 26 Aug 1996 01:59:31 -0400 (EDT)
Date: Mon, 26 Aug 1996 01:59:31 -0400 (EDT)
From: Gene Stark <gene@starkhome.cs.sunysb.edu>
Message-Id: <199608260559.BAA13245@starkhome.cs.sunysb.edu>
To: imp@village.org
CC: security@freebsd.org
In-reply-to: <199608260358.VAA06773@rover.village.org> (message from Warner Losh on Sun, 25 Aug 1996 21:58:46 -0600)
Subject: Re: Vulnerability in the Xt library (fwd) 
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>: 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.
>
>You'll have to be careful if you do this.  You'd need to make sure
>that you don't create something that the code inserted onto the stack
>can call and do an end run around the hard work you do in putting it

Of course, you're right, I didn't think this through properly.
However, this new system call could test to make sure that it is
being executed from the text segment, which is read-only, and refuse
to perform if not.
						- Gene Stark