I think is almost imposible avoid some logic errors,
you can avoid most common programming mistakes but in
most applications will remain logic (probably
exploitable) errors. There are logic errors that have
been present for long years in complex applications
without being noticed. Logic errors are very difficult
to detect.
eg:
/%25%2e double decode bug in IIS.

Cesar.

--- Glynn Clements <glynn.clements (at) virgin (dot) net [email concealed]> wrote:
>
> Valdis.Kletnieks (at) vt (dot) edu [email concealed] wrote:
>
> > > And one more thing...<this one might be
> intresting ;-)> Is it possible
> > > to write code that is completely secure and not
> exploitable?
> >
> > This is just a specific case of the question "Is
> it possible to write
> > totally bug-free code"?
>
> 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?
>
> 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 <glynn.clements (at) virgin (dot) net [email concealed]>

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[ reply ]