"McGovern, James F \(HTSC, IT\)" > I have been noodling the problem space of secure coding after attending > a wonderful class taught by Ken Van Wyk. I have been casually checking > out Fortify, Ounce Labs, etc and have a thought that this stuff should > really be part of the compiler and not a standalone product. > Understanding that folks do start companies to make up deficiencies > in what large vendors ignore, how far off base in my thinking am I?
You're on-track. Indeed, you can see little pieces of it happening. I'll use gcc as an example, because it's one of the most widely used C/C++ compilers in the world. In the last few years much has been added to gcc, including the ability to detect format string errors and many mechanisms to help counter buffer overflows (randomization, StackGuard & later IBM's ProPolice sort-of-reimplementation, etc.). I expect more detection and prevention mechanisms to go into gcc C/C++ compilers in the future. But I think you're not going far enough back. Compilers or interpreters are very much limited by the language (notation) they're trying to support. It's hideously hard to retrofit many kinds of detection into C/C++, because programs written in those notations just don't have enough information to easily determine if things are okay. Buffer overflows are an obvious example; they can't even OCCUR in most languages, but are rife in C/C++ because information about buffer size is not necessarily available to a buffer user (yes, I know about C++'s STL, but you don't HAVE to use it). Which is why separate tools are used -- the analysis work can be hideously hard. It's better to have a language (including its library) where the problem can't occur (e.g., because it's trivial to detect it) or is at least unlikely/hard (e.g., make the "easy" way the secure way). Java (and its clone C#) avoid many problems by DESIGN instead of happenstance, e.g., you can't (normally) have buffer overflows (in normal protected code they can't happen). Even stupid stuff like = vs. == mixing goes away (mostly). If a language is designed to make it EASY to do the right thing, the right thing is more likely to occur. PHP, especially old versions, is an obvious case in point. Old versions (where global_registers was true by default) are almost impossible to write secure software for. I will say that at least the PHP folks were willing to change their language when it was realized that their language's design made it nearly impossible to be secure. I wish they'd take more steps, but on the other hand, other language communities are unwilling to take even small steps to eliminate sharp edges from their languages. --- David A. Wheeler _______________________________________________ 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 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
