Re: Thou shalt have no other gods before the ANSI C standard

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

Date: Sun, 27 Feb 2005 21:08:20 +0000 (UTC)

Trevor L. Jackson, III wrote:
>Even if errant reads are a real problem, focusing on errant writes is
>probably not a mistake.

Agreed.

>> Until we can articulate some process, try that process out, and measure
>> its effectiveness, I don't think we will be able to tell for sure
>> whether that process will be adequate -- i.e., whether we will be able to
>> (justifiably) count on that process to eliminate all buffer overruns.
>> I have yet to see such evidence provided for any process currently known.
>
>There is room for further discussion here. The topic would be absolute
>value versus relaive value. The phrase "good enough" suggest that there
>is an absolute value or critera that should be applied. That path leads
>to the hopless goal of perfect software.

Why do we need to know whether our development methodology is good enough
(absolute criteria) to eliminate all buffer overruns? Because if our
development process is not good enough, then we ought to be taking
other steps to prevent or mitigate against such risks. For instance,
until we have a development process that is demonstrably "good enough"
to remove all buffer overrun defects, we should strive to use runtime
"hardening" techniques (such as memory-safe languages, automatic bounds
checking, StackGuard, non-executable stack and heap, sandboxing, program
shepherding, etc.) as well as architectural and design methods (privilege
separation, least privilege, decomposition according to security concerns,
etc.) chosen to limit the impact of such bugs. We may wish to use many
of these techniques anyway, but if we aren't sure that our development
process is good enough to remove all buffer overruns, that is an additional
motivation.

>> I don't trust myself to be able to reliably distinguish a non-exploitable
>> buffer overrun from an exploitable buffer overrun.
>
>OK I accept your opinion. Are there any other kinds of defects that
>have that property?

I guess it depends. Generally speaking, a good rule of thumb in
security is to be conservative. As Gwyn once put it (and I probably
will get the quote at least a little bit wrong), we should evaluate our
systems according to the worst failure mode that is at all plausible
under circumstances favorable to the attacker. Sometimes there is
an attack that we think probably is unlikely to be feasible (maybe it
requires a conjunction of the moon and stars), though we're not sure.
In such a case, it is often a good idea to fix the software to provably
eliminate the attack, even though we're not sure whether it would be a
real threat in practice.

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... We might have seen fewer buffer overruns if the latter had ... You can say that C strings work as defined, so any mistakes ... real problem, you want a real solution, and two come to ... programmers sometimes makes mistakes (hell, ...
    (sci.crypt)
  • Re: Thou shalt have no other gods before the ANSI C standard
    ... >> Why do we need to know whether our development methodology is good ... >> to eliminate all buffer overruns? ... >> an attack that we think probably is unlikely to be feasible (maybe it ... > But above you agreed that temporarily ignoring errant reads would not be ...
    (sci.crypt)
  • Re: Thou shalt have no other gods before the ANSI C standard
    ... > to eliminate all buffer overruns? ... > development process is not good enough, then we ought to be taking ... etc.) as well as architectural and design methods (privilege ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... Douglas A. Gwyn wrote: ... We're talking about the kind of buffer overruns ... >oversights, but more usually the result of an unacceptably ... >anything approaching a rational development process. ...
    (sci.crypt)