From owner-freebsd-security Mon Oct 29 23:23: 3 2001 Delivered-To: freebsd-security@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 943A537B405 for ; Mon, 29 Oct 2001 23:22:59 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id BAA26123; Tue, 30 Oct 2001 01:21:24 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Tue, 30 Oct 2001 01:21:24 -0600 (CST) From: Ryan Thompson To: Matt Piechota Cc: Luc , freebsd-security@FreeBSD.ORG, Krzysztof Zaraska Subject: Re: BUFFER OVERFLOW EXPLOITS In-Reply-To: <20011029133604.D17640-100000@cithaeron.argolis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matt Piechota wrote to Luc: > On Mon, 29 Oct 2001, Luc wrote: > > > Can one confirm we may prevent FreeBSD buffer overflow > > using this document: > > > > "GCC extension for protecting applications from stack-smashing attacks" > > http://www.trl.ibm.com/projects/security/ssp/ > > > > Why isn't FreeBSD built with such extension (by default) ? > > [...] > > On the other hand, stack overflows are generally due to sloppy > programming, so adding code and overhead to facilitate being lazy > seems to be the wrong way to attack a problem. Sure, C programmers need to stay on their toes. I follow security programming guidelines, regularly use code auditing tools (both automatic, and manual :-), all of the common testing patterns, and, invariably, after all of that, something still runs amok every 10,000 LOC or so at the end of the day. That's what script kiddies are for. :-) I do appreciate writing in other strongly typed languages, especially for string handling, because the whole pointer dance is alleviated.. Of course, don't forget that the code that these compilers generate all boils down to the same thing--pointers and memory. They're just using carefully coded libraries (hmm...) to add an extra layer between the programmer and the byte code. Yeah, we could take this back to the assembly language vs. machine code debate. (You're using our computer time to do WHAT?), or look forward to artificially intelligent libraries that accept "code" in the format of a decent task description, which will DEFINITELY be subject to programmer error, especially if it's in English. :-) Anyways, I'm all for safer a safer strcpy(3), etc., but I'm still of the opinion that C's weakness in that regard is also a strength. I'm NOT of the opinion that everyone should "brain up" and stop making mistakes, because that is simply unreasonable. :-) We all need to keep security in mind while coding, but, I also wouldn't mind it if my compiler slapped me more often when I coded something truly stupidly. (Better than being slapped months later with a page two article about how 14 year old kids "hacked" your software :-) I just don't think we're ever going to completely lose the human factor in this sort of thing, because there's always going to be somebody smart on the other end looking for a way in. - Ryan < more philosophical than usual :-) -- Ryan Thompson Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message