Date: Mon, 17 Feb 1997 15:04:54 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: cmott@srv.net (Charles Mott) Cc: msmith@atrad.adelaide.edu.au, freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow Message-ID: <199702170434.PAA07811@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.91.970216201528.1602A-100000@darkstar> from Charles Mott at "Feb 16, 97 08:30:46 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Charles Mott stands accused of saying: > > > > 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. Indeed, although you'd probaly want to page-align the stack, which reduces the search space somewhat. When you say that 'only new processes, not forked processes' would get a random stack, you're aware that this significantly reduces the effectiveness of this protection? (A long-running process like a webserver or MTA that forks to handle new connections becomes vulnerable to a walking search, or a binary serach if its behaviour differs on high/low misses). (I'm aware that the alternative would involve copying the stack to a new location on fork, which would be expensive.) > 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. I would be worried about the initial stack page not being mapped, but it (should) be fairly easy to track this down. > 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. 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. > 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. That's fair enough. > 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. > 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. > Charles Mott -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702170434.PAA07811>