From owner-freebsd-chat Sun Feb 16 19:31:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA18247 for chat-outgoing; Sun, 16 Feb 1997 19:31:16 -0800 (PST) Received: from darkstar (ras514.srv.net [205.180.127.14]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA18236 for ; Sun, 16 Feb 1997 19:31:06 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id UAA01620; Sun, 16 Feb 1997 20:30:48 -0700 Date: Sun, 16 Feb 1997 20:30:46 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Michael Smith cc: msmith@atrad.adelaide.edu.au, freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow In-Reply-To: <199702170312.NAA07248@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > My understanding is that the overflow attack must have an approximate > > idea (within a few kilobytes) of how to modify the return address. It > > has to know the absolute address of the code which is dumped in the > > overflow area of the stack. A few kilobytes of no-ops are added so the > > modified return address can have a little slop. > > Ah, I'm with you now, sorry. Unless the domain of the randomness was > large, this might not be more than a minor impediment, but it'd certainly > slow some things down. I think one gigabyte would be a fairly large domain of randomness. > Is the plan to pad the stack with unmapped pages, or to actually try to > relocate the stack? I am thinking just to change the initial value of the stack pointer. I don't know what the interaction with the memory manager will be. > You could start by modifying the definition of USRSTACK in > i386/include/vmparam.h and see if the kernel still runs (I suspect > some subtle problems with assumptions about the adjacency of the user > stack and the per-process kernel stack per the comment in locore.s). I'll start looking at the source code. Mainly, I just want to modify the initial value of the stack pointer for a user process, which should have a completely independent address space. > Bear in mind, though, that stack overruns smashing the return address > are only one of a family of hole sources; I think that the audit process > (find the holes and fix them for good) is a better long-term solution. The long term strategy is sound, but subject to human error. I think it isn't a bad idea to also overlay some general approaches which combat a class of security vulnerabilities. In any event, I just want to experiment a little with my own kernel. In the same vein, I don't think it would be such a bad idea to modify strcpy, so that if it thinks it is working on a stack variable, it will not overrun the frame pointer. I think someone may already have done this. There is a tendency among the freebsd team to look for perfect solutions. These security holes seem so severe, that I think some redundant overlay schemes are advised, even if they are not perfect. Charles Mott