Date: Mon, 17 Feb 1997 13:42:17 +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: <199702170312.NAA07248@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.91.970216194631.1548A-100000@darkstar> from Charles Mott at "Feb 16, 97 07:55:12 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Charles Mott stands accused of saying: > > 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. Is the plan to pad the stack with unmapped pages, or to actually try to relocate the stack? 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). 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. > 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?199702170312.NAA07248>