Les's C subset is good to consider. Also look into cyclone (cornell) and cquel.
From: Jim Mary Ronback [mailto:[EMAIL PROTECTED]
Sent: Thu Jul 08 08:30:30 2004
To: Dana Epp
Cc: [EMAIL PROTECTED]
Subject:Re: [SC-L] Education and security -- plus safety, reliability and
Dana Epp wrote:
I think they should be taught the powers and failures of C.
Your course sounds enticing. I'm tempted to sign up for it.
Your course should also make a clear distinction between security,
safety, reliability and availability.
One can write secure code that is not safe and vice versa - and one can
write reliable code that is not safe and vice versa - and one can write
reliable code that is not secure and vice versa. Finally one can write
code that is secure, safe, reliable but not robust and vice versa. In
many instances the software requirements, design and implementation
concerns for security, safety, reliability and availability overlap.
Safety ensures that bad things do not happen. Security ensures that
unauthorized access to information is not allowed. Reliability ensures
that the system and its software behaves as specified during a given
interval of time. Availability ensures that the system and its software
are not unavailable for use for more than a given period of time. Higher
availability is provided by failure tolerance to system and software
failures and human error.
I suspect that C has a pervasive hold because a large amount of legacy C
code exists. When modifying or enhancing existing C code one should use
a safer subset either by enforcing coding standards like in Safer C or
eliminating a large class of errors which are not allowed by some newer
C compilers, e.g., Safe C and Cyclone. If I had my druders, instead of
using C, I would chose Spark - the safer Ada subset which allows you to
guarantee that there are no runtime errors.
But if you are stuck with C, you should consider adding the following
book to the reading list in your security course. It provides an
extensive list of all the shortcomings and hazards of C.
(1995) Safer C: Developing for High-Integrity and Safety-Critical
Systems/ by Hatton, L.
/http://www.oakcomp.co.uk/SCT_About.html provides a corresponding
toolset to be used with Safer C/
The Safer C toolset goes to considerable effort to enforce the
well-known MISRA C standard. The MISRA C standard was developed by a
consortium of car manufacturers with the intention of introducing the
notion of safer language subsets for programmable control systems in the
There is also some interesting research to make C compilers safer but I
have not had any experience using them:
SCC: The Safe C Compiler -SCC is an optimizing C-to-C compiler which
implements the extended pointer and array access semantics needed to
provide efficient, reliable and immediate detection of memory access
errors in /unbridled/ C codes.
http://www.zork.org/safestr/ - Provides a safer string handling library
for for Safe C.
http://www.research.att.com/projects/cyclone/ provides another safer C
dialect. Here is a excerpt from their introduction:
Cyclone is a language for C programmers who want to write secure,
robust programs. *It's a dialect of C designed to be /safe/: free of
crashes, buffer overflows, format string attacks*, and so on. Careful C
programmers can produce safe C programs, but, in practice, many C
programs are unsafe. Our goal is to make /all/ Cyclone programs safe,
regardless of how carefully they were written. All Cyclone programs must
pass a combination of compile-time, link-time, and run-time checks
designed to ensure safety.
There are other safe programming languages, including Java, ML, and
Scheme. Cyclone is novel because its syntax, types, and semantics are
based closely on C. This makes it easier to interface Cyclone with
legacy C code, or port C programs to Cyclone. And writing a new program
in Cyclone ``feels'' like programming in C: Cyclone tries to give
programmers the same control over data representations, memory
management, and performance that C has.
This electronic message transmission contains information that may be
confidential or privileged. The information contained herein is intended
solely for the recipient and use by any other party is not authorized. If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited. If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message. Cigital, Inc. accepts