* Pascal Meunier:

> But it's true for stupid bugs like buffer overflows and format string
> vulnerabilities, in which we're still swimming, and the proof is the fact
> that those aren't possible in some languages.

Could you name a few such language implementations? 8-)

In most cases, the components that enforces the absence of buffer
overflows are written in C.  In other cases, languages have the
reputation of being free from buffer overflows although it's just not
true: You can create a fully conforming Common Lisp implementation
where code injection through buffer overflows is possible.  On the
other hand, it's possible to construct an ISO C implementation where
accessing memory beyond the end of a buffer is equivalent to calling
abort. (Such CL implementations are very common, but the C
implementatins aren't because they would feature a very unusual ABI or
suffer from poor performance.)

And you need to keep in mind that even with C, we are close to turning
buffer overflows into completely reproducible crashes.  This is not so
much different from supposedly safer programming languages where an
exception is raised in such cases.  The exception can be handled,
sure, but if it is truly unexpected, your system will fail.

>  For design/requirements bugs, I'm reading:

Safety-critical software is a very different beast.  You can make much
stronger assumptions about the environment.  It's not clear if the
results apply to software security in open system.

I'm not saying that formal methods have no value.  But I doubt that
comparisons with projects at completely different
dollars-per-line-of-code levels give immediate insights.
Secure Coding mailing list (SC-L)
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Reply via email to