[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CD PROPOSAL: CATSPEC (Interim Decision 8/24)

*strong* MODIFY (almost REJECT)

a) I don't understand item #2 below.  Why consider a vulnerability that
hasn't passed the EXCLUSION CD (or the INCLUSION one).  Or, does Exclusions
refer to something different, like the specific list of exclusions, in
which case it should be named differently.

b) I disagree with the sweeping statement that "software flaws are
concrete, well-understood entities that have been studied closely, thus it
is easier to specify how to discriminate between software flaws",
especially if all we know is that you can crash X if you do Y, thus it's a
"vulnerability" (i.e., there's a flaw, and an ensuing risk, somewhere)
against a DoS attack.

In my opinion, configuration problems are like the programmer offloading
the responsibility of programming the system correctly onto the user.  What
I mean is that what we sometimes call "software flaws" configuration
problems done at the programmation stage, with hard-coded values, sizes and
such.  Moreover, if the programmer decides to use algorithm A in case X and
algorithm B in cases Y and Z, and this causes a vulnerability, is that a
software flaw?  What happens if the choice is made configurable;  is it
then a configuration problem?  Or was it a configuration problem all along,
excepted that the bad configuration was done by the programmer instead of
the user?  The potential vulnerability hasn't changed, but the whole
content decision applied to it should be different according to this
proposal.  I don't see a hard boundary between configuration problems and
"software flaws".

If you want to assign a likely category to a vulnerability and process it
accordingly, and are aware of the problems this may cause, that's fine with
me, because there's a need to be practical and I don't see any better way
of doing it at the moment.  However, PLEASE remove the unnecessary and in
my opinion, incorrect part of the rationale.  Suffice it to say that
different categories of vulnerabilities require relevant decision criteria.

c) the second part of the "rationale" (order of CDs) is not a "rationale",
but part of the description.

Pascal


>
>(Member may vote ACCEPT, MODIFY, REJECT, or NOOP.)
>
>
>Short Description
>-----------------
>
>A vulnerability's category determines what content decisions are
>applied to it.
>
>
>Rationale
>---------
>
>In general, software flaws are concrete, well-understood entities that
>have been studied closely, thus it is easier to specify how to
>discriminate between software flaws.  Service/application presence
>problems are also concrete, since the name of the service suffices for
>discrimination.  However, configuration problems are poorly understood
>and have no well-defined language to describe them.  Thus content
>decisions related to configuration problems cannot be effectively
>described.
>
>The category of the vulnerability (as recorded in CMEX) allows an
>interested observer to understand which content decisions have been
>applied to the vulnerability, which thus affect the level of
>abstraction, inclusion in the CVE, etc.
>
>In cases where a vulnerability may have multiple categories, content
>decisions are applied in the following order:
>
>1) Pervasive
>2) Exclusions
>3) Software Flaw
>4) Configuration Problem
>5) Service/Application Presence
>
>If the existing content decisions are not sufficient for
>discriminating between vulnerabilities that the Editorial Board
>believes should be distinguished, then those content decisions need to
>be refined, or new ones added.
Page Last Updated or Reviewed: May 22, 2007