Date: Thu, 23 Jul 1998 12:20:53 +1000 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: security@FreeBSD.ORG Subject: Re: Projects to improve security (related to C) Message-ID: <98Jul23.122048est.40333@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
On Wed, 22 Jul 1998 18:23:24 -0400, Brian Cully <shmit@kublai.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98Jul23.122048est.40333>