Re: CD PROPOSAL: DEFINITION - Interim Decision 8/23

[Pascal Meunier <pmeunier@purdue.edu>]

MODIFY  -- remove the following ambiguity

I have a problem with "acceptance of a candidate by all voters implies
universality."  If I vote to accept a candidate based on the inclusive
definition of a vulnerability  -- because I understand what others want to
call a vulnerability --, that doesn't mean it is a universal vulnerability
in my opinion.  I think you mean that unanimous votes of "universal" imply
that the candidate is a universal vulnerability (in which case we vote on
two things at once)?  The above sentence suggests that I should vote to
REJECT all the vulnerabilities that I don't consider "universal"
vulnerabilities, in contradiction with the opening statements of the
proposal.

Pascal

>Board members who advocate a universal vulnerability definition may be
>surprised at this proposal, since most of the discussion on the
>mailing list was in support of the universal definition.  However, it
>was clear from the CVE Review meeting (and by voting patterns on
>specific candidates by less vocal participants) that a number of Board
>members advocate using an "inclusive" vulnerability definition
>(a.k.a. "risk," or "environmental vulnerability," etc.)  It is this
>discovery that provides one of the strongest arguments AGAINST using
>"Silence Implies Assent."
>
>Please register your vote to the list or just to me.
>
>- Steve
>
>
>
>Content Decision: DEFINITION (Use "Inclusive" Vunerability Definition)
>----------------------------------------------------------------------
>
>VOTE:
>
>(Member may vote ACCEPT, MODIFY, REJECT, or NOOP.)
>
>
>Short Description
>-----------------
>
>The CVE uses an Inclusive vulnerability definition, but CMEX indicates
>whether each entry is also a Universal vulnerability.  Editorial Board
>members must therefore vote on candidates in accordance with the
>Inclusive vulnerability definition.
>
>
>Definitions
>-----------
>
>A "universal" vulnerability is one that is considered a vulnerability
>under any commonly used security policy which includes at least some
>requirements for minimizing the threat from an attacker.  (This
>excludes entirely "open" security policies in which all users are
>trusted, or where there is no consideration of risk to the system.)
>
>The following guidelines, while imprecise, provide the basis of a
>"Universal vulnerability definition."  A Universal vulnerability is a
>state in a computing system (or set of systems) which either:
>  - allows an attacker to execute commands as another user
>  - allows an attacker to access data that is contrary to the
>    specified access restrictions for that data
>  - allows an attacker to pose as another entity
>  - allows an attacker to conduct a denial of service
>
>An "inclusive" vulnerability is not a universal vulnerability, but it
>may be considered a vulnerability under at least some commonly used
>security policies.
>
>
>Rationale
>---------
>
>Discussions on the Editorial Board mailing list, and during the CVE
>Review meetings indicate that there is no definition for a
>"vulnerability" that is acceptable to the entire community.  However,
>there appears to be a "minimal" definition of vulnerability which is
>common to all definitions.  In general, the "minimal definition" is
>strongly advocated by those with an academic perspective, while many
>of those who represent operational constituencies (e.g. tool vendors
>or response teams) advocate an approach that has a less stringent
>definition, since the term is broadly used by the constituencies that
>they serve.
>
>In accordance with the original stated requirements for the CVE, the
>CVE should remain independent of multiple perspectives.  Since the
>definition of "vulnerability" varies so widely depending on context
>and policy, the CVE should avoid imposing an overly restrictive
>perspective on the vulnerability definition itself.  Therefore, the
>CVE should not use a "universal" vulnerability definition that is
>acceptable to all, but instead use an inclusive definition.
>
>There is a good use for both definitions, however.  But maintaining
>completely separated enumerations is not feasible.
>
>In recognition of the utility of a "universal" vulnerability
>definition, CMEX should contain an attribute which indicates whether a
>vulnerability is "universal" or not.  Voters for individual candidates
>may identify whether they believe a candidate is a "universal"
>vulnerability; acceptance of a candidate by all voters implies
>universality.
>
>Advocates of a "universal" vulnerability definition can easily extract
>the appropriate portion from the CVE, while allowing the CVE to be
>used by those who need a more inclusive definition.  Thus the CVE can
>adequately serve both "universal" and "inclusive" advocates.  To take
>the opposite approach, i.e. to only include universal vulnerabilities,
>would only adequately serve "universal" advocates.
>
>
>Examples
>--------
>
>Examples of universal vulnerabilities include:
>  - phf (remote command execution as user "nobody")
>  - rpc.ttdbserverd (remote command execution as root)
>  - world-writeable password file (modification of system-critical
>    data)
>  - default password (remote command execution or other access)
>  - denial of service problems that allow an attacker to cause a Blue
>    Screen of Death
>  - smurf (denial of service by flooding a network)
>
>Examples of inclusive vulnerabilities include:
>  - running services such as finger (useful for information gathering,
>    though it works as advertised)
>  - inappropriate settings for Windows NT auditing policies (where
>    "inappropriate" is enterprise-specific)
>  - running services that are common attack points (e.g. HTTP, FTP, or
>    SMTP)
>  - use of applications or services that can be successfully attacked
>    by brute force methods (e.g. use of trivially broken encryption,
>    or a small key space)