Cardinality, classes was Re: Issues for configuration problems in the CVE

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

[This is from Pascal Meunier, who attempted to post it from a
different email address than the one the list server knows.]



Date: Sat, 17 Jul 1999 12:33:49 -0800
To: cve-editorial-board-list@lists.mitre.org
From: Pascal Meunier <pascalm@cup.hp.com>
Subject: Cardinality, classes was Re: Issues for configuration problems in
 the CVE

I think we're getting off track when the words "class" or "classify" enters
the argument.  All that matters is that all problems that allow policy
violations to occur, are given a CVE number.  It seems pointless to me to
try to list only "true" vulnerabilities when we don't agree on what a
vulnerability is.  Likewise, discussing the properties (e.g., cardinality)
of a class of vulnerabilities is invinting debate on defining a
classification, as this discussion demonstrates.  Give a CVE entry to each
particular problem and argue later on what it is and how it came about.
The CVE should be a list of observations, that does not attempt to
aggregate some into classes (e.g., "reducing their cardinality"), because
that violates its mandate.

<rant>
I vote for having one entry for each default password/account, secret or
not.  I vote for having an entry for each option, each switch in a command
line argument, each line in a .conf or .ini file, each bit in a control
access list, etc... that resulted in an observed mismatch between intent
and reality.  And, I don't care who installed it or if it's an operator
error.  If it's hard enough to use that it results in frequent user errors
that resulted in actual vulnerabilities, I want it listed -- it's a design
flaw in my book.  Hard-to-use *is* a source of vulnerabilities, just like
being hard to program, so it doesn't matter if it's operator error or
programmer error -- it's an error that results in a vulnerability.
</rant>

I am very uncomfortable with the strong emphasis given to reducing
cardinality in the CVE, because that can be a source of errors, ambiguity,
and incompleteness.
Pascal

>At 1:13 PM -0400 7/16/99, Steven M. Christey wrote:
>>Gene Spafford wrote:
>>
>> >When I first had a student (Taimur Aslam) look at classifications of
>> >problems, configuration errors fell out as one category.  However, we
>> >found there were some ambiguities with user interface error, and
>> >incorrect documentation.  If something is misconfigured because the
>> >documentation is unclear (or wrong), is that a bug?  If so, where?  In
>> >the software that doesn't match the documentation, or in the
>> >documentation that doesn't match the software?
>>
>>I see why the questions needs to be asked from a perspective of
>>classification and explanation; however, I don't think this particular
>>issue has much of an impact on the CVE.  The configuration problem
>>exists because of something a user did, regardless of how the user did
>>it or why they did it.  I believe that's sufficient for the CVE.
>>
>>- Steve
>
>The documentation and online help message says "-s" is the security
>mode switch.   The user builds a config file to run with "-s".
>However, it turns out that either the programmer got the logic
>backwards, or the documentation is wrong, and "-s" turns the security
>OFF.   The result is a vulnerability.
>
>Is that a bug or an operator error?
>
>The system comes with default accounts with well-known passwords.
>The operator does not notice these, and installs the system with the
>accounts intact.   This results in a vulnerability.
>
>Is that an operator error?
>
>The system comes with a program that installs patches.   The vendor
>releases a patch to a problem.   The operator runs the program, and
>in addition to installing the patch, it sets some directory
>permissions and ownerships to new values that result in a
>vulnerability.
>
>Is that a bug or operator error?
>
>
>In each case, " The configuration problem exists because of something
>a user did, regardless of how the user did it or why they did it," so
>I would assume you would classify them all as operator errors.
>However,  all three are also vulnerabilities that are in some sense
>"built in" by the vendor.
>
>I would argue that #2 is the only one that is directly a user error.
>Problems that occur because the operator should have know better if
>he/she had read documentation and security literature fall in this
>category.  Vulnerabilities that result from hidden features, bugs,
>bad documentation of features, etc are not.
>
>Comments?