-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of der Mouse
Sent: 12 April 2005 05:15
To: SC-L@securecoding.org
Subject: Re: [SC-L] Theoretical question about vulnerabilities
[B]uffer overflows can always be avoided, because if there is ANY
input
On 4/13/05, der Mouse [EMAIL PROTECTED] wrote:
I would question you if you suggested to me that you always assume
to _NOT_ include 'security' and only _DO_ include security if
someone asks.
Security is not a single thing that is included or omitted.
Again, in my experience that is not
So you blame the grunts in the trenches if you lose the war? I mean,
that thinking worked out so well with Vietnam and all... ;-)
regards,
-dsp
I couldn't agree more! This is my whole point. Security isn't 'one
thing', but it seems the original article [that started this
discussion] implied that
[B]uffer overflows can always be avoided, because if there is ANY
input whatsoever that can produce a buffer overflow, the proofs
will fail and the problem will be identified.
Then either (a) there exist programs which never access
out-of-bounds but which the checker incorrectly flags as
der Mouse wrote:
[B]uffer overflows can always be avoided, because if there is ANY
input whatsoever that can produce a buffer overflow, the proofs will
fail and the problem will be identified.
Then either (a) there exist programs which never access out-of-bounds
but which the checker incorrectly
David Crocker wrote:
Exactly. I'm not interested in trying to write a program prover that will prove
that an arbitrary program is correct, if indeed it is. I am only interested in
proving that well-structured programs are correct.
The Hermes programming language took this approach
