From owner-freebsd-security Sun Aug 25 23:34:08 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA21115 for security-outgoing; Sun, 25 Aug 1996 23:34:08 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA21099 for ; Sun, 25 Aug 1996 23:34:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id XAA00528; Sun, 25 Aug 1996 23:33:45 -0700 (PDT) Message-Id: <199608260633.XAA00528@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Warner Losh cc: Gene Stark , security@FreeBSD.org Subject: Re: Vulnerability in the Xt library (fwd) In-reply-to: Your message of "Mon, 26 Aug 1996 00:05:52 MDT." <199608260605.AAA07212@rover.village.org> From: David Greenman Reply-To: dg@root.com Date: Sun, 25 Aug 1996 23:33:45 -0700 Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >: 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. > >Well, couldn't the code that was inserted onto the stack copy itself >somewhere handy, make that a read only text segment, and make these >calls? > >Why is the stack segment executable in the first place? Or does Intel >require this? There isn't any notion of "executable" in the x86 page table mechanism. You could probably use the user code selector to limit execution to low (lower than the stack) addresses, but you'd have to deal with the signal trampoline. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project