[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 To: email@example.com From: Pascal Meunier <firstname.lastname@example.org> 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?