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

["Steven M. Christey" <coley@linus.mitre.org>]

Pascal Meunier said:

>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.

I stated that incorrectly.  I meant "Exceptions" (e.g. EX-BETA beta
code or EX-BRUTE brute-force-only problems) which were one of the
bullets in the EXCLUSION CD.  Exceptions should be placed as another
condition of INCLUSION.

>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.

By that statement, I meant to say that software flaws, once adequately
analyzed and diagnosed, are concrete.  In general, you'll know the
particular line of code where the crash occurs, and you'll know the
execution path that was taken to lead to that particular line of code.

If you don't know what the specific flaw is that allows X to be
crashed when you do Y, then the associated vulnerability is not
sufficiently understood.  But once you find out that the vulnerability
is due to "buffer overflow" or "shell metacharacter," then you have
some degree of understanding of the nature of the vulnerability.

I agree that the statement is a little sweeping.  How about this one?
"At this time, software flaws are better understood and more
concretely described than other categories of vulnerabilities."

>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...  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".

I agree that there are some cases where there is ambiguity, and we
should treat them on an ad hoc basis, then refine the content
decisions as a result.

I think the following statement is a good assessment of where I'm
coming from:

>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.

The desire is to be as consistent and practical as possible.

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

Agreed.  Note that the imposed order of the CD's could also help to
provide some consistency in handling "multi-category" vulnerabilities
like the one you described above, although we still may not be able to
address all the intricacies of the problem.

- Steve