Re: [Lit.] Buffer overruns

From: David Wagner (daw_at_taverner.cs.berkeley.edu)
Date: 02/02/05 

Date: Wed, 2 Feb 2005 10:19:01 +0000 (UTC)

infobahn wrote:
>David Wagner wrote:
>> But once you know a small set of common C pitfalls, I'm not sure how
>> much knowing the rest of the spec helps with buffer overruns.
>
>Oh, I'm sorry. I thought we wanted, ideally, a program with no bugs.
>I didn't realise that you *only* wanted programmers to be concerned
>with eliminating buffer overruns. In any case, wouldn't you agree
>that you're more likely to get a program with no buffer overruns if
>you use skilled programmers who consider /any/ bug to be bad news?

I was restricting attention to buffer overruns just because
that was what this thread is about, and because of the claim that ABC
would be pointless if programmers would only follow your discipline.
Since your discipline placed such an emphasis on knowing the C spec,
I think it is only fair to question whether this part of your discipline
is really contributing anything to rendering ABC pointless.

But if you'd like to broaden the scope to all 'exploitable security
bugs', that's fine with me. I'm happy to replace 'buffer overruns'
with 'security bugs' in the above passage. So let's try again.

Once you know a small set of common C pitfalls, I'm not sure how
much knowing the rest of the spec helps with security bugs. What do
you think?

(I do not accept broadening the scope to include all bugs, including
non-security bugs. That's a totally different discussion.)

>> Suppose we quantify the value of knowing each section of the C spec by
>> the number of buffer overruns that have occurred and that could only be
>> recognized/spotted/avoided if you know section of the C spec. What do you
>> think the value, by this metric, of the sections of the C spec will be?
>
>With the greatest of respect, I think the question makes no sense,
>for reasons I have already outlined.

Ok. I'm happy to replace 'buffer overruns' with 'security bugs' in
the above passage. So let's try again.

Suppose we quantify the value of knowing each section of the C spec by
the number of security bugs that have occurred and that could only be
recognized/spotted/avoided if you know section of the C spec. What do you
think the value, by this metric, of the sections of the C spec will be?

>I think the metric is of no value. It would be much more valuable to
>measure the correlation (an *inverse* correlation, one would hope!)
>between knowledge of the spec and bugs in production code.

But as you know, you can have correlation without causation. I outlined
one plausible way that we could have a non-causal correlation in my previous
post (i.e., a common cause for both "introduces few bugs" and "deep knowledge
of C spec"). I can think of several other possibilities. And if this is
indeed a non-causal correlation, knowing the degree of the correlation
doesn't tell you much for the purposes of this discussion, because this
discussion is about predicting whether learning more of the C spec will
cause you to introduce fewer bugs.

>My experience has been that learning significantly more about C has
>significantly reduced the number of errors I make in my programs.

Is the same true when you restrict attention to exploitable security
errors? If so, can you give an example or two of how deep knowledge
of the C spec has helped you avoid exploitable security errors? (that
might be very hard to do, so if that is too hard, I will understand and
not draw conclusions from that fact)

Relevant Pages

  • Re: Some of Rons Code?
    ... It didn't fail in flight. ... pretty bad since they did have an entire separate team of attack programmers who in friendly/adversarial way attempted to find bugs, which caused the first team to super-check code before releasing it to the test group so they could not find bugs. ... The funny thing about this being that the original article said that they had a fix but that the extensive retesting required had not been completed. ... Their brains have to fall asleep and follow the spec as dumbly as computers obey our code, or at least there exists unusual pressure in that direction-- I am sure many things do get picked up by programmers and kicked back to the design team. ...
    (comp.lang.lisp)
  • Re: Yet another Attempt at Disproving the Halting Problem
    ... > proof that is purported to show that a correct Halt Analyzer can not exist, ... that is "correct" in conforming to the spec "correctly predict ... NO BUGS are added! ... But NOBODY IS PROPOSING ...
    (comp.theory)
  • Re: Yet another Attempt at Disproving the Halting Problem
    ... > proof that is purported to show that a correct Halt Analyzer can not exist, ... that is "correct" in conforming to the spec "correctly predict ... NO BUGS are added! ... But NOBODY IS PROPOSING ...
    (sci.logic)
  • Re: Minimal keywords needed for constructing a full CL system
    ... their are bugs and incompleteness in lisp implementations. ... Yet they all attempt to conform to the spec. ... In fact, an English spec is far better than a reference implementation, because ... Well, the test suite can have errors itself, but that's the point of the ...
    (comp.lang.lisp)
  • Re: Maybe a stupid question...
    ... in game. ... I see it all the time, and not knowing who/what it is bugs the hell ...
    (alt.games.warcraft)