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 / aleph1at_private
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:06:27 PDT