RE: opinion, ACM Queue: Buffer Overrun Madness

["Alun Jones" <alun () texis com>]

[EMAIL PROTECTED] <> wrote on Wednesday, June 09, 2004 7:58
AM: 
> Although I am in favor of languages that help prevent such nasties as
> input buffer overruns, this is an excellent point.  A sloppy
> programmer will write sloppy code.  Reminds me of an old saying that I
> heard years
> ago while studying mechanical engineering: a determined
> programmer can
> write a FORTRAN program in ANY language.  :-)  (Well, notwithstanding
> FORTRAN's built-in ability of handling complex numbers, but I
> digress...) 

Going back over some of my old FORTRAN code, I find that I was writing
object-oriented code in FORTRAN.  Going over other people's C++ code, I can
see that they're trying to make it work like FORTRAN, or QuickBASIC, or
something like that.

I did some work recently on .NET Security, trying to come up with some
examples that would demonstrate how you'd screw it up in code.  It's
certainly difficult to come up with bad examples that aren't needlessly
bone-headed, but when you look at other people's code, you realise that an
awful lot of programmers are bone-headed.  Buffer overflows can happen in
any language, no matter what those languages do to prevent them.

Okay, that's a bold statement.  I'd better back it up.  If you have a
string-handling library of any kind, someone's going to come up with a
program design that builds a twenty character string for a person's name,
putting first name in the first ten characters, and last name in the last
ten characters.  Eric Smith changes his first name to Navratilova, and he's
suddenly listed by the program as "Navratilovamith amith" - buffer overflow.
Sure, it doesn't overflow into the stack, but it overflows into important
data.  And if you want to go further into insanity, you can manufacture a
case where character 11 being lower case causes unwanted code to be executed
(no default condition in a 'case' statement, no good error handling, etc).

> IMHO, the bottom line is that there's no excuse for sloppiness and a
> strong language can only do so much to prevent the programmer from
> his/her own sloppiness. 

The first defence against unsecure coding is to hire and educate your
developers in such a way as to exclude the unsecure coding practices.  It's
not the only defence - but it's the first you're going to need, because if
you don't have that, you've got programmers who will flout security
prevention measures _because_ they don't understand how to do it properly,
or why they're being strong-armed in a particular direction.

And on the topic of hiring better programmers, I'm now in my third week as
[EMAIL PROTECTED]  [But my personal address remains this one]

Alun.
~~~~