Re: A way to prevent buffer overflow exploits?

khays@sequent.com (Kirk Hays)
16 Aug 1998 22:42:57 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: A way to prevent buffer overflow exploits? toon@moene.indiv.nluug.nl (Toon Moene) (1998-08-02)
Re: A way to prevent buffer overflow exploits? dlmoore@pgroup.com (David L Moore) (1998-08-02)
Re: A way to prevent buffer overflow exploits? pizka@informatik.tu-muenchen.de (1998-08-03)
Re: A way to prevent buffer overflow exploits? fjh@cs.mu.OZ.AU (1998-08-04)
Re: A way to prevent buffer overflow exploits? bear@sonic.net (Ray Dillinger) (1998-08-10)
Re: A way to prevent buffer overflow exploits? eodell@pobox.com (1998-08-13)
Re: A way to prevent buffer overflow exploits? khays@sequent.com (1998-08-16)
Re: A way to prevent buffer overflow exploits? shriram@cs.rice.edu (Shriram Krishnamurthi) (1998-08-16)
Re: A way to prevent buffer overflow exploits? conway@cs.mu.OZ.AU (1998-08-16)
Re: A way to prevent buffer overflow exploits? genew@vip.net (1998-08-17)
Re: A way to prevent buffer overflow exploits? conway@cs.mu.OZ.AU (1998-08-17)
Re: A way to prevent buffer overflow exploits? chase@world.std.com (David Chase) (1998-08-19)
Re: A way to prevent buffer overflow exploits? eodell@pobox.com (1998-08-19)
[2 later articles]
| List of all articles for this month |

From: khays@sequent.com (Kirk Hays)
Newsgroups: comp.compilers
Date: 16 Aug 1998 22:42:57 -0400
Organization: Sequent Computer Systems, Inc.
References: 98-07-242 98-08-014 98-08-029 98-08-081
Keywords: C, practice

fjh@cs.mu.OZ.AU (Fergus Henderson) wrote:
>>A better approach is to use safer programming languages, especially
>>for security-critical applications. Who ever heard of a buffer
>>overflow exploit for a program written in Java, Sather, Haskell, or
>>Mercury?


Eric O'Dell <eodell@pobox.com> wrote:
>Maybe I'm missing something here, but aren't buffer overflows
>completely preventable by simply not reading more data into the buffer
>than it can contain?


That's the theory. In practice, after you've had legions of
programmers marching through a source code, stuff happens. Most
programming languages make it worse, with C being a particular
offender. Don't get me started on the semantic gap between design
documents and implementation.


Type safe languages aren't a cure-all. Bad programmers can make bad
code in any language, and good programmers are in the minority, and
great programmers are rare (present company excepted), so I expect to
see "buffer overflow exploits" (how cute!) type errors for the
indefinite future.


Programming in C (for example) is like juggling a running chainsaw
with no chain clutch, handle, off switch, or safety guards. It can be
done, spectacular results can be achieved, but you know it's going to
be painful on occasion.


>IMHO, if this is a problem for your organization, it's a sign that
>your hiring practices, and not your programming tools, are at fault.


Oh, my.


So the programmers you hire never have a bad day, an "off by one"
error, program on a Friday afternoon, fight with their spouses, lack
experience, misuse a macro, get bit by a bug in a compiler, or have to
maintain someone else's crufty old code?


Beware hubris.


I admire your dedication to the ideals of our shared Art, but remind
you that the only "science" in "Computer Science" is in the name.
After 20 years of programming daily for a living, I find that arcanum
is still the order of the day, and Murphy is our high priest.
--
Kirk Hays
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.