From owner-freebsd-security Sat Feb 8 13:34:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA01148 for security-outgoing; Sat, 8 Feb 1997 13:34:11 -0800 (PST) Received: from alpha.risc.org (trt-on7-45.netcom.ca [207.181.82.173]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA01123; Sat, 8 Feb 1997 13:34:01 -0800 (PST) Received: from localhost (taob@localhost) by alpha.risc.org (8.8.4/8.8.4) with SMTP id QAA17490; Sat, 8 Feb 1997 16:33:41 -0500 (EST) Date: Sat, 8 Feb 1997 16:33:40 -0500 (EST) From: Brian Tao To: "Jordan K. Hubbard" cc: pst@freebsd.org, FREEBSD-SECURITY-L Subject: Re: Don't fulminate, be productive (was Re: Karl fulminates, film at 11. == thanks) In-Reply-To: <7610.855424259@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 8 Feb 1997, Jordan K. Hubbard wrote: > > Actually, that's a good 50% of it. The other 50% is replacing > strcpy()'s with strncpy()'s. :-) I'm sure a perl hacker could come up with a script that can at least flag some sort of warning where it suspects a line of code may be susceptible. A grep through the sources only finds about 6000 occurrences of sprintf or strcpy. ;-) BTW, has anyone been able to get a FreeBSD version of Insure++ or Purify (or whichever product it was) and run the source tree through it? > Seriously, looking for bufffer overflows is not rocket science, > though if you spot more serious bugs along then way then you are > more than free to fix them. :-) I'm definitely no code hacker, so I think I'd be limited to standalone user space utilities and leave library routines and kernel stuff to the experts. Still, it would be an instructional exercise, even if no potential holes are found. I think Marc Slemko went over the Apache sources in similar fashion and submitted a bunch of security-related patches. > I'm still waiting for Paul to give me us accumulated archive of > volunteers before kicking this off - we had a slight communications > failure and both ended up thinking that the other was keeping the > master list. :) Doh. :) -- Brian Tao (BT300, taob@risc.org) "Though this be madness, yet there is method in't"