"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.

Reply via email to