RE: Bug-free software

[Andreas Saurwein <saurwein () uniwares com>]

At 5/2/2004 21:25 Thursday, David Crocker wrote:

> > * Bugfree at the operation level would mean that the program is bugfree
whatever you do with it
<<

I'm still not sure what you mean by "bugfree at the operational level". Maybe
you mean that the software should behave reasonably for all possible inputs
(i.e. not crash, nor suffer from buffer overflows etc. that might expose
vulnerabilities or give rise to other undefined behaviour). If this what you
mean, then I agree that this is an important part of being "bug-free". A 
program
should be robust with respect to all possible inputs. This is certainly an 
area

that mathematically-based methods address.


Exactly this - operational by means of data which the program processes. 
This might be user input, a string from a database or the content of a file 
downloaded from the internet or simple unicode string.


As software engineers we have the huge advantage over most other engineers 
that

the materials we use _don't_ degrade over time. The ways in which software is
used does change, but it is not necessary to anticipate all the changes. For
example, Internet Explorer has suffered from a number of buffer overflow
vulnerabilities. This I regard as inexcusable, because a complete package 
should
be robust for all possible inputs. OTOH the recently-patched "phishing" 
bug that
allowed a link to point to one page that appears (from the IE address box) 
to be

a different page is more understandable, because the requirement that the
address box should always be the address of the page displayed might have been
easily missed before "phishing" scams became widespread.


"robust for all possible inputs" is what I would classify as "bugfree at 
the operational level".
But where is the difference between a buffer overflow and a displaying only 
part of the data? In both cases the reason is insufficient length 
information and validation of the data.


On the other hand, our materials DO kind of degrade in the meaning that the 
data volume and data content may significantly change, while the processing 
does not.




> >
Most string handling routines are technically bugfree in the given
specification, yet they cause problems because of operational failures
(parameters).
<<

I'm not sure what you mean by this - an example would be helpful. If you mean
that it is possible to crash them by providing invalid parameters, then 
this is

not a bug - provided that the specification clearly states the preconditions
under which parameters are acceptable.


Correct. But using parameters which are outside of the specifications may 
result in a severe problem.
Where is the guilt then? With the user who provided invalid input? With the 
function which did not validate the users input according to the 
specifications? In the string handling function because it does not check 
for parameters which are not covered by the specs?
In the end the blame is on the string function because its there where the 
actual damage occurs, and nobody will ask if the function works according 
to the specifications.


I think if it was possible to cover the operational level without thorough 
validation routines, say at the language or compiler level, most of the 
common vulnerabilities would be avoided.


(I think I took that thread to a very philosophical point.)

Andreas