Re: at the risk of another flamefest..

[stagda () ncs com (David Stagner)]

If I may fan the flames further... I often wonder if we should blame
our Language of Choice, rather than bad programming practice.  It
seems to me that the bulk of code-based security problems these days
are buffer overflow-related.  Is this characteristic of poor coding,
or a misfeature of C?

I'm hesitant to say that C is a bad language just because [] is just
an overloading of *.  To me, C is just a generalization of the Von
Neumann architecture, and the array/pointer congruence reflects the
reality of our hardware.  But in the practical case, it is the source
of most of our non-algorithmic bugs, particularly security bugs.

Many, many well-proven languages handle array bounds checking for the
programmer, and do so efficiently.  It seems to me a Bad Thing, and
bad programming practice, for the programmer to need to explicitly
check for overflow on every single array operation.  We should just be
able to do the obvious and expect the language to fail gracefully when
we do what should not be possible.

Of course, there are SOME cases when we might want to be able to write
off the normal end of an array.  However, I submit that these cases
are extremely rare for most unix utility and daemon programming.  In
other words, if you NEED the power of C, then by all means use it.
But if not, perhaps you should consider using a more sophisticated
language for security-sensitive coding, something that doesn't expect
you to do ALL the work.

What we need is a powerful, portable, widely used language that
automagically handles bounds checking for us.  Sounds like perl to
me.:}

-dave