RE: Writing Secure code

A proposal:

Since a lot of the discussion on this thread (including my own contributions) has focused on semantic issues such as defining "secure code", why not take a stab at a working definition for secure code so we can get down to brass tacks?

For starters, let's go with a paraphrase of the definition provided by John Viega:

   Code that is not in and of itself exploitable through a flaw    its implementation.

with the following stipulations:

1. It is not practical to determine whether or not non-trivial code is "bug-free". As stated before, that would require testing all possible paths with all possible inputs in all possible environments. Even if it was possible, it would be extremely tedious. :-)
2. Generally, the developer can only control how input to the program (including return codes, signals, etc) is handled, not how external resources function. For example, the developer can't really do squat if Oscar P. Malware trojans libc so that it transmits the data from each and every *printf call to his dark black hat lair.

--McC

-- 
Matt McClellan               Sr. Software Engineer
mmcclellan@nfr.com           NFR Security, Inc.