From owner-freebsd-hackers Tue Feb 4 20:32:58 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64F5737B401 for ; Tue, 4 Feb 2003 20:32:57 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65EC743F43 for ; Tue, 4 Feb 2003 20:32:56 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h154VX7m002502; Tue, 4 Feb 2003 20:31:33 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h154VXY7002501; Tue, 4 Feb 2003 20:31:33 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Tue, 4 Feb 2003 20:31:33 -0800 From: David Schultz To: Garance A Drosihn Cc: "Brandon D. Valentine" , Justin Lundy , FreeBSD-Hackers Subject: Re: [eugene@securityarchitects.com: Re: Preventing exploitation with rebasing] Message-ID: <20030205043133.GA2168@HAL9000.homeunix.com> Mail-Followup-To: Garance A Drosihn , "Brandon D. Valentine" , Justin Lundy , FreeBSD-Hackers References: <20030204195114.GA92636@cvs.tegatai.com> <20030204201043.GR16038@geekpunk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Garance A Drosihn : > 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