Date: Sun, 16 Feb 1997 22:07:11 -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.970216215017.1692A-100000@darkstar> In-Reply-To: <199702170434.PAA07811@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Not quite sure what you mean here; the stack has to be in the same > virtual address space as the rest of the program, othewise it wouldn't > be possible to indirectly reference automatic variables or execute > trampolies on the stack. I thought you were talking about stacks existing in kernel space, as opposed to user space. Initially, I just want to deal with user space vulnerabilities. What I don't understand is what block of addresses is reserved in a process for the stack. The calls to malloc() have to know how to avoid this space. Are a fixed number of stack pages allocated at process creation? Don't worry about answering these questions. I am just thinking aloud and can work out the details myself. > > 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. > > I certainly wouldn't be willing to buy this as a useful device, > particularly as the frame pointer isn't guaranteed. I think strcpy() can tell whether it is working on an automatic variable by looking for proximity to the stack pointer. However, it the frame pointer isn't guaranteed, then strcpy() would not be able to determine an upper bound for the length of the copy. In any event, there would be other copy functions to work on also. > > > 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. > > I think that in general the FreeBSD team does a good job of tempering > expediency with experience and perspective. There has been a great > deal of largely unwarranted noise and fuss about security of late, and > I commend the core team for keeping their heads while lesser mortals > have made fools of themselves. I don't necessarily think an emergency code audit is the way to go. However, it is a good idea to have a lot of people looking over the code. My tendency would be to identify security holes but not have a load of individual fixes. A few broad strategic moves are preferable in my view. What other security holes exist, other than stack overflow variations, which allow an intruder to take over a machine? Charles Mott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970216215017.1692A-100000>