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