Cardinality, classes was Re: Issues for configuration problems in the CVE
[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
From: Pascal Meunier <email@example.com>
Subject: Cardinality, classes was Re: Issues for configuration problems in
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.
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.
I am very uncomfortable with the strong emphasis given to reducing
cardinality in the CVE, because that can be a source of errors, ambiguity,
>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.
>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
>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.