Secure Coding mailing list archives
RE: opinion, ACM Queue: Buffer Overrun Madness
From: "Alun Jones" <alun () texis com>
Date: Wed, 09 Jun 2004 19:47:41 +0100
[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. ~~~~
Current thread:
- opinion, ACM Queue: Buffer Overrun Madness Jose Nazario (Jun 08)
- Re: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 08)
- Re: opinion, ACM Queue: Buffer Overrun Madness der Mouse (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness Kenneth R. van Wyk (Jun 09)
- RE: opinion, ACM Queue: Buffer Overrun Madness Alun Jones (Jun 09)
- RE: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness Blue Boar (Jun 10)
- Re: opinion, ACM Queue: Buffer Overrun Madness der Mouse (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness der Mouse (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 08)
- Re: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness David Eisner (Jun 09)
- <Possible follow-ups>
- RE: opinion, ACM Queue: Buffer Overrun Madness Peter Amey (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness Gary McGraw (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 09)
- RE: opinion, ACM Queue: Buffer Overrun Madness David Crocker (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness Jared W. Robinson (Jun 10)