Re: at the risk of another flamefest..

[stagda () NCS COM (David Stagner)]

Mike Neuman writes:
>   To fan the flames a bit, I find it amazing that people are complaining
> that C is at fault for their lousy programming...

That's hardly what I said.  What I'm saying is that the shortcomings
of C means that programmers must use significantly more effort and
skill to avoid security problems.  Some of these are very subtle (like
the problems with gets() bounds checking (or lack thereof)), and can
only be learned through lots of experience.  And we cannot
realistically expect ALL our code to be written by programmers with
extensive security experience.

In my eyes, a lot of "lousy programming" is simply using the wrong
tool for the job, and then having to do kludgy workarounds to make up
for the shortcomings of the tools.  Case in point: programmers
shouldn't HAVE to explicitly bounds-check every array operation in
order to avoid security problems.  The language should be able to
handle overflow on its own.  Explicitly checking every operation
introduces potential bugs, and is a clear violation of KISS.  The
first step to secure code is clean code.  And the hoops we must jump
through because of C's weak typing and crude memory management are the
antithesis of clean code.  If a programmer misses a non-obvious
memory-related security problem through error or naivete, is this
"lousy programming"?  I don't think it's that simple.

>   In any case, to add yet another level of indirection to the above argument,
> Mr. Bradley is forgetting that Unix itself is written in C. As a result, perl
> may have no bound problems, and so will the resulting compiled perl code, but
> the operating system itself could still have problems (a la syslog() ).
>
> -Mike
> mcn () EnGarde com

Yep.  No matter how carefully you choose a better language for
security, you're still stuck with someone else's C code with all its
risks.