From owner-freebsd-security Fri Jun 26 21:11:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07248 for freebsd-security-outgoing; Fri, 26 Jun 1998 21:11:11 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from brooklyn.slack.net (root@brooklyn.slack.net [206.41.21.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07239 for ; Fri, 26 Jun 1998 21:11:07 -0700 (PDT) (envelope-from pfm@brooklyn.slack.net) Received: from localhost (pfm@localhost) by brooklyn.slack.net (8.8.7/8.8.7) with SMTP id AAA06975; Sat, 27 Jun 1998 00:13:43 -0400 (EDT) Date: Sat, 27 Jun 1998 00:13:42 -0400 (EDT) From: Patrick McAndrew To: jtb cc: Wojciech Sobczuk , fpscha@schapachnik.com.ar, Niall Smart , ncb05@uow.edu.au, security@FreeBSD.ORG Subject: Re: non-executable stack? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 26 Jun 1998, jtb wrote: > Actually, Brian Matthews brought this idea up to me last fall, and the > more I've been thinking about it lately, why not just deny a handful of > ctrl-char's that a buffer overflow needs, i.e. 0x90, 0xff, etc. I'd have > to say there is a minimal number of ctrl-char's we can disallow to stop > your average script kiddie from sending shellcode into a process via > cmdline or environment arguments. This method won't really protect > against attacks involving sscanf()'ing data from files ala the Vixie Cron > bug for RH 4.x, but security will definitely be improved with minimal > loses funcionality-wise. Let me know what you guys think. All replies > are welcomed, critical or not. Why bother? Just practice good security programming and check bounds. It would be much easier to fix a getc() call than to write an entire function that checks for certain control characters that were passed.. Rember, "keep it simpe stupid" :) Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message