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