Date: Tue, 4 Feb 2003 20:31:33 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Garance A Drosihn <drosih@rpi.edu> Cc: "Brandon D. Valentine" <brandon@dvalentine.com>, Justin Lundy <jbl@cvs.tegatai.com>, FreeBSD-Hackers <FreeBSD-Hackers@FreeBSD.ORG> Subject: Re: [eugene@securityarchitects.com: Re: Preventing exploitation with rebasing] Message-ID: <20030205043133.GA2168@HAL9000.homeunix.com> In-Reply-To: <p05200f62ba6637bbfd04@[128.113.24.47]> References: <20030204195114.GA92636@cvs.tegatai.com> <20030204201043.GR16038@geekpunk.net> <p05200f62ba6637bbfd04@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Garance A Drosihn <drosih@rpi.edu>: > I agree that random offsets will not buy much in the way of > security, but it might make some kinds of initialization errors > more obvious. I'm thinking of the kind of errors where a routine > forgets to initialize a key variable, but everything "seems to > work" because the routine happens to always pick up the same > value off the stack. By adding random offsets, the routine > *might* at least behave differently each time it's run. Nondeterminism is nearly always a bad thing when debugging. Maybe random stack offsets would be a useful component in some sort of stress test, but I'm not sure I'd like to see such a feature used in production. As far as preventing buffer overflows goes, there are already enough ad hoc techniques like Stack Guard out there that only lessen the impact of a bug, and even then only sometimes. A much better approach is to develop better coding practices (better language features) and use static checking for legacy code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030205043133.GA2168>