Re: [Lit.] Buffer overruns

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 12/31/04 

Date: Fri, 31 Dec 2004 14:46:51 -0700

"Douglas A. Gwyn" <DAGwyn@null.net> writes:
> Is that relative frequency or absolute frequency? Normalized how?
> If 99% of the apps are in C and 95% of the bugs are in C then that
> would show that C seems much less bug-prone than the other
> languages.
>
> Changing the environment does not help if the bugs are not *caused*
> by the environment. Since most bugs of the kind under discussion
> are caused by bad thinking, they will persist into other
> environments.

percent of failures/exploits for the specific environment that are
related to buffer overflows. I'm only looking at percentage of all
reported exploits/vulnerabilities types (for a specific environment)
that happen to be related to buffer overflows.

that should normalize it for amount of use of specific kind of
environment (both across the number of different applications ... as
well as the frequency that such applications are used).

long ago and far away ... a large commercial mainframe environment
routinely had customers sending detailed trace and memory image copies
to the vendor as part of problem determination and resolution. the
standard tool used by the vendor basically dealt with the information
in hex and had the vendor employees doing problem determination (&
resolution) performing manual examination of the trace and storage
image(s).

I completely rewrote the tool ... minor random references
http://www.garlic.com/~lynn/subtopic.html#dumprx

and added a bunch of programmable analysis features. I then did a
detailed study of the reported types of failures and the failure
signatures .... so i could automate much of the failure analysis
process for the most common failure characteristics.

the vendor failure management and reporting structure (tried to)
mapped all occurance of a specific failure cause to a single failure
occurance (regardless of the number of times the same customer and/or
different customers would report that specific failure).

in any case, at that time i got to have a pretty complete look at all
customer reported failures and did a pretty detailed analysis of the
structural characteristics related to the failure in order to build
automated failure signature analysis.

the cve database effort appears to also be attempting to map all
occurances of a specific failure cause to a single failure reporting
entry (not taking into account the number of times that the related
program might have been observed to have had that failure).

some more random drift ... earlier I had done a detailed analysis of
all kernel serialization related failures i.e. hung/zombie processes
and/or using pointers after the related operations had all be
completely and discarded ... which sometimes also involved pointers to
location zero ... minor reference to hardware guard rail from a
recent posting here (low storage protect)
http://www.garlic.com/~lynn/2004q.html#82 [Lit.] Buffer overruns

then as part of releasing the operating system resource manager
product ... i completely rewrote the kernel serialization primitives
to completely eliminated all instances of hung/zombie processes as
well as dangling pointer use. random past pointers to the resource
manager product
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#bench

so when my wife and i started the project producing the ha/cmp (high
availability, cluster multiprocessing) product in the late 80s
... minor refs
http://www.garlic.com/~lynn/95.html#13
and
http://www.garlic.com/~lynn/subtopic.html#hacmp

we started with detailed failure and vulnerability study to try and
identify all possible failure characteristics. it was then that we
predicted that common c programming environments would have an order
of magnitude (or more) increase in the percentage of failures that
were buffer length related (compared to other environments that we had
experience with).

and of course to slightly bring this back to crypto ... two people
at the mentioned meeting
http://www.garlic.com/~lynn/95.html#13

were then at another company (that was doing this thing called
https/ssl) in charge of doing something called commerce server.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Relevant Pages

  • Re: Science and Religion
    ... Norse interacted with, and adapted to, their surroundings, both ... consequently led to the failure of the settlements. ... appropriate to the fragile environment. ... This exchange represents an ancient problem, ...
    (soc.retirement)
  • Re: Science and Religion
    ... Norse interacted with, and adapted to, their surroundings, both ... consequently led to the failure of the settlements. ... appropriate to the fragile environment. ... This exchange represents an ancient problem, ...
    (soc.retirement)
  • Re: How to have unittest tests to be executed in the order they appear?
    ... the failure. ... Sometimes it's the environment that's changed. ... In that case, I would recommend a change to the test *reporter*, so ... that the tests are still run in an arbitrary sequence, ...
    (comp.lang.python)
  • Re: Please help me to catch this error
    ... mainreturns an int value because that's how it is defined. ... in it's task), and 0 (which is interpreted as success, like ... Even in your MSDOS environment, ... or failure of the programs it initiates. ...
    (comp.lang.c)
  • Re: 1352 NUL bytes at the end of a page?
    ... Andrew Morton wrote: ... >> We've got a user who's reporting BK problems which we've traced down to ... >> correct file data picks up again after the hole. ... at the same time as the bk failure, ...
    (Linux-Kernel)