Date: Sun, 16 Feb 1997 19:55:12 -0700 (MST) From: Charles Mott <cmott@srv.net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow Message-ID: <Pine.BSF.3.91.970216194631.1548A-100000@darkstar> In-Reply-To: <199702170243.NAA07044@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970216194631.1548A-100000>