From owner-freebsd-chat Sun Feb 16 18:55:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA16296 for chat-outgoing; Sun, 16 Feb 1997 18:55:39 -0800 (PST) Received: from darkstar (dialin1.anlw.anl.gov [141.221.252.101]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA16290 for ; Sun, 16 Feb 1997 18:55:36 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id TAA01572; Sun, 16 Feb 1997 19:55:12 -0700 Date: Sun, 16 Feb 1997 19:55:12 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Michael Smith cc: freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow In-Reply-To: <199702170243.NAA07044@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 On Mon, 17 Feb 1997, Michael Smith wrote: > Charles Mott stands accused of saying: > > What I have noticed running test programs is that the top of the stack > > always appears to be at or near 0xffffffff. I am interested in generating > > an experimental kernel patch (for 2.1.0-R) which would randomly change the > > top stack address over a range of 0x4fffffff 0xffffffff when a a new > > process (not a fork) is started. > > > > My guess is that this will practically shut down any stack overflow > > attacks which gain root privilege. They may still cause crashes or > > process termination, though. > > > > Please advise if there is a conceptual error in what I want to do. I have > > There is a conceptual error in what you want to do. > > Stack accesses are _relative_. 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. Does anyone have a working example of something that exploits the old setlocale() security hole. I think this will settle any questions for me and stop having these imprecise discussions on the newsgroups. I remember getting similar garbage thrown at me when I started the packet aliasing project, which works just fine and is useful to quite a few people now. I may be wrong here, but in any event I need more intelligent responses than what has just been lobbed out by Mr. Smith. Charles Mott