Bounds Checking

[aleph1 () DFW NET (Aleph One)]

I've been out of town for a few days. This is why you've seen some
delays on some messages. Things should be back to normal.

Onto the C as a dangerous language argument. It seems this topic
always brings the religious zealots, raving lunatics and the plain
clueless out of the woodwork. I've killed most of the replies to the
thread. I will be allowing some of the more constructive criticism.

To make my bias clear, I do consider C code compiled with a compiler
that does not bounds checking to be more error prone that some other
strongly typed bounds checking languages. I am as guilty as the rest
of writing code in C when I might have been able to write it using
something else. Its difficult to break bad habits. I just happen to have
been discussing this topic the other day with some people. These are the
usual arguments pro C and against changing the status quo.

  - You can write secure programs in any language (including C).
    You can write insecure programs in any language (including C).

    True. You can also write secure programs in assembly. You don't see
    many people trying. Even the best programmers will make mistakes and
    most of the software you will want/need to run will not be written by
    the best programmers. Which of these two cases does programs like
    sendmail, named, imapd, popd, etc fall under left as an exercise for
    the reader. Bounds checking adds extra layer of security.

  - The are security vulnerabilities other than buffer overflows (which
    also affect bounds checking compilers/languages).

    True, but unless you plan on solving all security vulnerabilities
    at the same time you must start somewhere. Buffer overflows seem to
    be as good a place as any to start. They compose the largest segment
    of security vulnerabilities reported now a days.

  - Other alternatives are not as fast as C.

    If you put performance over security this is probably not a mailing
    list for you. This is also weak argument in a age when you can buy
    400 Mhz Pentium II processors for next to nothing while prices
    drop every day and process speed increases.

    I also consider it good practice to program with security and good
    design in mind first and then look for the hot spots to optimize. You
    can then turn off bounds checking selectively to improve performance
    on those sections of code that you feel confident enough will be
    secure. The usual risk/cost tradeoff.

   - The are no good open source alternatives.

     This is indeed a problem although the are some alternatives.
     For example the GNAT Ada 95 compiler and the Kaffe Java JIT
     compiler.

     In the area of modifying gcc to generate bounds checking code
     another person has posted links to several implementations.
     I'll let you pick up those links from his message.
     There is also the work on StackGuard to generate code that
     protects the functions return address.

   - The are not many libraries available for other languages.

     This is also a problem. Such libraries would have to be
     developed for other languages or bindings into the C libraries
     would have to be made. Of curse this last options is just adds
     a wrapper around possibly unsecure code. Then again any new
     libraries would not be as mature and will likely contain their
     own security problems. Catch 22.

  - You should audit the code instead of changing the language.

    Auditing the code should be a high priority on everyone's list. The
    work that people like the OpenBSD project, and now the Linux Auditing
    Project, have done and are doing is commendable. Yet as we
    have seen even auditing has not stopped some buffer overflows
    from being discovered in these systems.

    Any problem has be attacked from different direction. There
    is no such thing as complete security. Bounds checking
    compilers are just another security layer to complement source
    code auditing.


All this being said I do not see anyone moving away from C. There has
been to much money invested in C over the years to back away now.
To much code has been written in C that must be maintained. Universities
teach students C because they know students will need this skill when
they join the workforce. Vendors look for people with C knowledge because
they know this is what students have learned and its what their programs
are already written in. It all makes for a nice little circle. C has
become to programming languages what Windows is to operating systems. No
one is ever fired for coding in C. The only hope I see to attack the
problem from this angle is to wait for the the bounds checking C compilers
to become more mature and start being used more widely.

I might as well add also that if you won't/can't use such a compiler you
might at least use some debugging tools such as Purify, ElectricFence,
etc. and do some input validation testing. I will also point out the
L0pht's SLINT as useful tools for finding security problems in source
code: http://www.l0pht.com/slint.html

Aleph One / aleph1 () dfw net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01