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 (at) nfr (dot) com [email concealed] NFR Security, Inc.

[ reply ]