[SC-L] Bugs and flaws

[Crispin Cowan]

John Steven wrote:
> Re-reading my post, I realize that it came off as heavy support for
> additional terminology. Truth is, we've found that the easiest way to
> communicate this concept to our Consultants and Clients here at Cigital has
> been to build the two buckets (flaws and bugs).
>   
My main problem with this terminology is that I have only ever seen it
coming from Cigital people. The rest of the world seems to treat "flaw"
and "bug" as synonyms.

The distinction here is between "design flaw" and "implementation flaw".
There doesn't seem to be anything in these words that suggest one is
larger scale than the other.

>From dictionary.com we have:

flaw^1 <http://www.answers.com/flaw&r=67>(flô) pronunciation
/n./

   1. An imperfection, often concealed, that impairs soundness: /a flaw
      in the crystal that caused it to shatter./ See synonyms at blemish
      <http://www.answers.com/main/ntquery;jsessionid=75e32c5vb2csr?method=4&dsid=1555&dekey=B0319900&gwp=8&curtab=1555_1&sbid=lc04b>.
   2. A defect or shortcoming in something intangible: /They share the
      character flaw of arrogance./
   3. A defect in a legal document that can render it invalid.

"Bug" <http://www.answers.com/bug&r=67> is a little more arcane, and the
only relevant part is far down the document where it discusses the
history with Grace Hopper:

    bug

    An unwanted and unintended property of a program or piece of
    hardware, esp. one that causes it to malfunction. Antonym of
    /feature/
    <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FF%2Ffeature.html&gwp=8&curtab=2291_1>.
    Examples: “There's a bug in the editor: it writes things out
    backwards.” “The system crashed because of a hardware bug.” “Fred is
    a winner, but he has a few bugs” (i.e., Fred is a good guy, but he
    has a few personality problems).

    Historical note: Admiral Grace Hopper (an early computing pioneer
    better known for inventing /COBOL/
    <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FC%2FCOBOL.html&gwp=8&curtab=2291_1>)
    liked to tell a story in which a technician solved a /glitch/
    <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FG%2Fglitch.html&gwp=8&curtab=2291_1>
    in the Harvard Mark II machine by pulling an actual insect out from
    between the contacts of one of its relays, and she subsequently
    promulgated /bug/
    <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FB%2Fbug.html&gwp=8&curtab=2291_1>
    in its hackish sense as a joke about the incident (though, as she
    was careful to admit, she was not there when it happened). For many
    years the logbook associated with the incident and the actual bug in
    question (a moth) sat in a display case at the Naval Surface Warfare
    Center (NSWC). The entire story, with a picture of the logbook and
    the moth taped into it, is recorded in the /Annals of the History of
    Computing/, Vol. 3, No. 3 (July 1981), pp. 285--286.


> What I was really trying to present was that Security people could stand to
> be a bit more thorough about how they synthesize the results of their
> analysis before they communicate the vulnerabilities they've found, and what
> mitigating strategies they suggest.
>   
Definitely. I think there is a deep cultural problem that people who fix
bugs or flaws tend to over-focus on the micro issue, fixing the specific
coding vulnerability, and ignore the larger architectural error that
allows the coding defect to be exploitable and cause damage. In the case
at hand, the WMF bug would be much less dangerous if there were not so
many ways to induce IE to invoke WMF decoding without asking the user.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption