From owner-freebsd-hackers Wed Feb 12 09:21:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA12186 for hackers-outgoing; Wed, 12 Feb 1997 09:21:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12175 for ; Wed, 12 Feb 1997 09:21:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA00703; Wed, 12 Feb 1997 10:10:20 -0700 From: Terry Lambert Message-Id: <199702121710.KAA00703@phaeton.artisoft.com> Subject: Re: Increasing overall security.... To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 12 Feb 1997 10:10:19 -0700 (MST) Cc: dk+@ua.net, snar@lucky.net, freebsd-hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Feb 12, 97 11:28:24 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ ... stack checking ... ] Not that I believe it is necessary to implement at this level, or that this level would be valid on another architecture, such as SPARC, but... > To play devil's advocate... > > 1) It requires assembler which is harder to understand. Less people are > qualified to review it. Relying on something harder to understand for > security is questionable. This is not a "security through obscurity" issue. The code is hard to understand because of the people trying to understand it, not because the difficulty in understanding it is one of the intentional effects. > 2) We don't know if it operates correctly. Sendmail 8.8.5 has around 106 > strcpy's in it and we don't know what the patch's effect will be in a > production environment. I can tell you what the effect will be: (a) It will be a performance hit because of the extra runtime overhead (b) It will be relied upon, such that programs which are "secure" in a BSD environment because of it will suddenly become "insecure' when moved to another environment In general, this type of change is useful for a "debug" library, like those used by "Purify" and similar tools, but less useful as a general security precaution because of its limited scope (ie: it makes things safe on BSD on Intel, where the code in general is not repaired. I would advocate changing sensitive code to be secure in any environment, regardless of stack protections. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.