Re: Writing Secure code

Valdis.Kletnieks@vt.edu wrote:

> > And one more thing...<this one might be intresting ;-)> Is it possible

Maybe, maybe not; it depends upon how you define such terms. I can think of reasonable definitions of "bug" and "vulnerability" such that the former isn't a superset of the latter. To provide a (rather crude) example:

 Bug: the program doesn't do something which it is meant to do.  Vulnerability: the program does something which it isn't meant to do.

However, a program typically has only finitely many requirements but infinitely many non-requirements.

Is it a vulnerability if a program fails to wipe data from memory, or allows it to be written to swap, or slack space, or "unused" parts of files? Or if a network client can deduce which parts of certain files are memory-resident by sending carefully chosen requests and analysing the timing of the server's responses?

For a program to be "secure", exactly *what* must it *not* do?

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

>From a reliability (no bugs) perspective, one can specify that e.g.
input timings don't affect the output data and are therefore irrelevant, and it's pretty straightforward to make it so.

>From a security (no vulnerabilities) perspective, ensuring that the
input data don't affect the output timings is (at a guess) somewhere between insanely difficult and downright impossible; and simply deeming them to be irrelevant doesn't help at all.

So, while it might be possible to produce a "completely reliable" program (modulo the requirement that all other components behave exactly as specified; IOW, not necessarily fault-tolerant), I'm not sure that "completely secure" is a meaningful concept.

-- 
Glynn Clements