Argh! Re: [CD] CD Proposal: SF-EXEC (Software flaws in multiple executables)

[Pascal Meunier <pmeunier@purdue.edu>]

>The following content decision (CD) is related to cases in which the
>same software flaw appears in multiple executables within the same
>software package.
>
>CD Proposal Date: 6/12/2000
>Voting Period: 7/10/2000
>Final Decision: 7/24/2000
>
>
>************************************************************************
>CD:SF-EXEC (Software flaws in multiple executables)
>************************************************************************
>Type: ABSTRACTION
>Version: 1.0
>Proposed: 6/12/2000
>Final Decision: N/A
>
>
>
>Short Description
>-----------------
>
>If the same software flaw appears in multiple executables in the same
>package, then record it in a single entry.
>
>
>Definitions
>-----------
>
>All definitions are informal.
>
>A "software package" is loosely defined as a collection of software
>that is normally bundled together, provides a single overall
>capability, and is offered on the same platform by a single vendor, or
>for multiple platforms by the same developer.

I hate this CD; it feels like trying to grasp wet corn starch.  You
think that you have it defined and then it escapes.

Lots of things can be bundled together -- e.g., MS Word and
Powerpoint are bundled together in MS office.  If you don't like this
example because of the "single capability" qualifier, the MS Word
installation contains "equation editor" and more executables that
support MS Word.  Where does this start and where does it stop?  OS
distributions?  I see this as a continuum of possibilities with no
clear boundaries in the middle.  It would make more sense for me to
specify that if you can't install something separately without losing
its usefulness, then what it is a member of is a software package.

A more fundamental problem with this CD is that you need to know all
about the similar flaws in all of the executables before voting.  The
way things have been going, this could significantly delay the
acceptance of candidates (information paralysis).  Perhaps a solution
would be to favor having a speedy CVE entry as the first (or first
few) flaw is found, and having "append proposals" that would add to
the initial CVE entry, as more information in the flaws of other
executables is found.  These "append proposals" could be useful in
other situations as well, whenever a CVE entry needs updating (e.g.,
as new vulnerable versions are released).  They should carry
information that should not result in a new CVE entry.

What if a vendor tries to fix all of them, but one of them escapes?
You could find yourself in a situation where A says that they fixed
CVE-xxxx-xxxx, B saying that it is still there, and scanning software
C and D testing for the existence of this CVE vulnerability by
different methods that yield opposite results.

Another problem is the dependence on changing architectural and
software engineering concepts that have to be reverse-engineered
(read "guessed at") by us.  It is also possible that in the future,
these concepts will be obsolete.  As an example (perhaps feeble), how
would you characterize (classify?) code that is dynamically generated
for you from outside your "PC" by a trusted source and then run on
your machine, perhaps in a sandbox?  Most likely, whether that
(binary) code is from a "library", the same or a different
"executable" will be transparent to you, and perhaps those concepts
would be meaningless -- you subscribed to a "service".  That code
could be changed every day, perhaps even every time you change
preferences.  Would you then make a new CD?  How do you deal with
having to rebuild the CVE with a new CD, or having part of the
database be defined by version 1 of a CD and another part defined by
version 2?

In conclusion, I feel that the less you need to know about a
vulnerability to make a CVE entry, the better (aka the 'KISS'
principle).  This CD is mostly an attempt at optimization of the
storage requirements of the CVE, that comes at too high a cost -- it
comes close to a classification attempt.  I think that this CD should
not be adopted, and that we should avoid such complexity, delays and
potential confusion as much as possible.  Much of what I said here
applies also to SF-LOC.

"One entry per identifiable instance"
Pascal
"You cannot build a happy private life in a corrupt society anymore
than you can build a house in a muddy ditch."
Anonymous Czech woman, from the 2000 Commencement Address by Bill
Moyers about the american political system