Date: Fri, 17 Jul 1998 15:49:02 -0700 (PDT) From: Craig Spannring <cts@internetcds.com> To: bugtraq@netspace.org Cc: Anonymous <nobody@replay.com>, freebsd-security@FreeBSD.ORG Subject: Buffer overflows. was Re: EMERGENCY: new remote root exploit in UW imapd Message-ID: <199807172249.PAA11364@bangkok.office.cdsnet.net> In-Reply-To: <199807170035.RAA05041@bangkok.office.cdsnet.net> References: <199807162206.AAA30072@basement.replay.com> <199807170035.RAA05041@bangkok.office.cdsnet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
The responses I've gotten can be grouped into the following broad
categories-
1) Life would be good if we eliminated C and we will.
2) Life would be good if we eliminated C, but we can't.
3) C is the only language fast enough.
3) Eliminating buffer overflows is nice, but won't solve most of
the problems.
3) You can write safe code in C using strncpy, snprintf, et al.
4) Only morons write code with buffer overflows
5) Modula-2 and Ada suck and you do you.
I doubt the C will be eliminated for a long time, but we need to
analyze the risks of using C for critical applications.
It has been demonstrated by repeated assertion that C is faster.
10,000 lemmings can't be wrong. C doesn't provide enough information
to the compiler for certain classes of optimizations.
People that say eliminating buffer overflows won't have much benefit
need to examine some data. I took a look at some recent bugtraq
messages. Out of 19 security defects 7 of them were buffer overflows,
6 were design or coding flaws, 1 was a tradeoff of 1 problems
vs. another, 1 was a protocol weakness, 1 was the result of not
checking validity of user supplied data before executing with /bin/sh
and 3 were unknown. (CERT advisories have _so_ much detail.) Of the
buffer overflows 6 gave you root privileges. With the 6 design flaws
only one gave you root privs. Of the 8 problems that resulted in a
root compromise, 6 of them were buffer overflows.
Writing in a language that prevents buffer overflows won't solve all
of the problems, in fact it won't even solve half of the problems, but
it's a good start.
I agree that if you use C you must use the functions that take a
length parameter. In fact the next time I'm asked to look at a major
piece of C my first step will be grep '(strcpy)|(sprintf)|...' *.c.
But since C doesn't pass the dimensions of arrays into functions
you're job is a lot harder than it should be.
I've repeatedly heard that in the hands of a good programmer that C is
safe and it is only morons write code with buffer overflows. A lot of
people seem to think that Eric Allman is a pretty sharp programmer,
but even he had a few overruns in sendmail. Look around your office.
How many of the programmers are exceptional, how many are average and
how many are mediocre. If even the good ones run into problems
what hope do the average and mediocre ones have?
Here's two snipets of (buggy) code, one in C and one in Java.
Assuming both are compiled, which one could give root access and which
one throws an exception?
// Java
do {
buf[i] = getNextByteFromNextwork();
while ('\n' != buf[i++]);
/* C */
do {
buf[i] = getNextByteFromNextwork();
while ('\n' != buf[i++]);
Half of the programmers out there are below average. Do we want them
writing code in C?
BTW- I must say I was surprised at the number of personal attacks I've
received in regards to this message. It seems like there are a lot of
people that are threatened at the very idea of some language other
than C. As Mr. Spock would say, "Fascinating". Comments regarding my
parentage, education or IQ are not relevant to the discussion of
making safe and secure server programs and will be ignored.
--
=======================================================================
Life is short. | Craig Spannring
Ski hard, Bike fast. | cts@internetcds.com
--------------------------------+------------------------------------
Any sufficiently perverted technology is indistinguishable from Perl.
=======================================================================
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?199807172249.PAA11364>