* 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) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php