From owner-freebsd-security Wed Jul 22 19:25:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA17861 for freebsd-security-outgoing; Wed, 22 Jul 1998 19:25:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA17629 for ; Wed, 22 Jul 1998 19:23:23 -0700 (PDT) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40333>; Thu, 23 Jul 1998 12:20:48 +1000 Date: Thu, 23 Jul 1998 12:20:53 +1000 From: Peter Jeremy Subject: Re: Projects to improve security (related to C) To: security@FreeBSD.ORG Message-Id: <98Jul23.122048est.40333@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 22 Jul 1998 18:23:24 -0400, Brian Cully wrote: >On Tue, Jul 21, 1998 at 12:58:59PM -0600, Brett Glass wrote: >> In the meantime, there are some things that can be done even with the >> code still written in C. we can (and must!) bite the bullet and kick sprintf, >> vsprintf, and similar functions OUT of the libraries. Yes, it'll be a >> bit of a pain, but... no pain, no gain. > >Uhh... what? I seriously hope you're not suggesting that programmers >should not have access to the various un-bounds-checked functions. What Brett suggests might be a bit impractical, but we can easily give [v]sprintf() et al the same treatment as gets(): If the linker currently sees a reference to gets(), it reports "warning: this program uses gets(), which is unsafe." The same message is written to stderr when gets() is called. I don't believe it is reasonable to apply the same stigma to the (unchecked) str...() functions - they are not inherently unsafe (unlike gets() and many [v]sprintf() calls). This does bring up the issue of where to draw the line as far as `unsafe' functions are concerned. I can think of the following standard functions which have the potential for buffer overflows when used correctly (ie parameter types are appropriate and passed buffers match their passed sizes etc): *scanf(), [v]sprintf(), gets(), wctomb(), strcpy() and strcat(). I suspect it would be relatively difficult to exploit wctomb(). Has anyone tried looking for exploits using *scanf() functions? I have often thought about building a bounds-checking sandbox for debugging C code using C++ by overloading [], ->, unary * and unary &. The killer is the amount of effort needed to re-define all the builtin types and define the appropriate (template) class. (And there may be some gotchas with differences between ANSI C and C++ - I haven't looked too hard at that side). Depending on the resultant slowdown, it might be practical to live with the result in this form. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message