Re: Thou shalt have no other gods before the ANSI C standard
From: Brian Inglis (Brian.Inglis_at_SystematicSW.Invalid)
Date: 02/27/05
- Next message: gerard46: "Re: [XPOST] A unique number for every "person" - can it be done?"
- Previous message: David Wagner: "Re: Thou shalt have no other gods before the ANSI C standard"
- In reply to: Trevor L. Jackson, III: "Re: Thou shalt have no other gods before the ANSI C standard"
- Next in thread: Trevor L. Jackson, III: "Re: Thou shalt have no other gods before the ANSI C standard"
- Reply: Trevor L. Jackson, III: "Re: Thou shalt have no other gods before the ANSI C standard"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 27 Feb 2005 21:10:52 GMT
On Sun, 27 Feb 2005 14:33:06 -0500 in alt.folklore.computers, "Trevor
L. Jackson, III" <tlj3@comcast.net> wrote:
>David Wagner wrote:
>> Trevor L. Jackson, III wrote:
>>
>>>We need to distinguish reads from writes. I'm assuming you are
>>>interested in errant writes rather than errant reads. Are you aware of
>>>any exploits based upon errant buffer reads?
>>
>>
>> Nothing really significant. I know of a few examples of exploits based
>> upon errant reads, but they were were "information disclosure" or "crash
>> the machine" vulnerabilities, rather than something that immediately
>> leads to the ability to take control of the machine. However, if your
>> application isn't handling any important secrets, errant reads seem like
>> a pretty low-priority item, I would think -- it seems to be pretty rare
>> to encounter a buffer overrun that leads to some kind of serious information
>> disclosure vulnerability but does not allow attackers to take control of
>> the application.
>
>Even if errant reads are a real problem, focusing on errant writes is
>probably not a mistake.
>>
>>>There's a similar idiom, NCHECK, that can be used to control
>>>the compilation of parallel implementations, one for production (speed,
>>>size, etc) and one for correctness (big & slow). The NCHECK symbol is
>>>most useful when it controls not only comparison of the results, but
>>>also comparison of the process.
>>
>> I take it this is another way of describing 2-version programming,
>> except done at a fine granularity, and with more detailed checking of the
>> results of the computation? I think I understand what you are suggesting.
>
>I failed to mention that the NCHECK code should be written by someone
>other than the author of the non-NCHECK code. This technique is decades
>old, and is a far more useful technique than the eXtreme Programming
>paradigm of writing the tests first. Making the code evaluate itself
>yields a more effective coverage metric.
Can also be used by the author, writing a separate validation module
that checks and cross-checks the internal data integrity, after data
has been acquired and "validated" by the input code, usually in a more
isolated manner.
>>>Of course in the impersonal sense you are correct. But I'd like to hear
>>>your description of what "good enough" would be. Can you articulate a
>>>criteria than can be applied at the project level to determine whether
>>>hat project is good enough or not?
>>
>> I'm not sure we know what would be "good enough". How could we tell?
>> The only way I know to tell is to do a controlled experiment and measure.
>> 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.
>
>The alternative or relative or incremental value, such as disciplined
>methodolgy or automated error checks is easier to envision, but does not
>guarantee "enough" improvement to materially reduce the icidenc the of
>exploits. After all, any given progam needs only one serious
>vulnerability, so finding all but the last one does not increase the
>effective security of the system. Also, along this path lies hype
>because we still lack a metric for (in)security.
There are a number of predictive measures for estimating the remaining
number of defects from the number already found.
OTOH the Lockheed-Martin US space shuttle software team has metrics
that allow them to predict how many defects to expect in a new
release, so if their validation processes come up short on the count,
they institute a bug hunt to find the balance. But the process is
expensive at ~$35M/year for 100 people supporting ~420KLOC IIRC.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
- Next message: gerard46: "Re: [XPOST] A unique number for every "person" - can it be done?"
- Previous message: David Wagner: "Re: Thou shalt have no other gods before the ANSI C standard"
- In reply to: Trevor L. Jackson, III: "Re: Thou shalt have no other gods before the ANSI C standard"
- Next in thread: Trevor L. Jackson, III: "Re: Thou shalt have no other gods before the ANSI C standard"
- Reply: Trevor L. Jackson, III: "Re: Thou shalt have no other gods before the ANSI C standard"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
