Re: [TECH] CD:VAGUE (Vague Vendor Descriptions of Vulnerabilities)

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

Is this item open for discussion or not?  I see this as a change in the focus of the CVE from vulnerabilities to patches and a kind of Pandora's box.  

1. If entries about patches ("problems fixed") are allowed, then because it's easier to list patches than vulnerabilities, the CVE may slide that way.  

2. If just announcing a patch is enough for the CVE that of course won't help motivate vendors to give any further information (although I'm not sure how much the CVE really influences them).  Taken to an extreme, this could lead to an hypothetical advisory stating in its entirety, "the new version of our software has better security, everyone should upgrade now".  Do you want to create a CVE entry for that?  

3. Vulnerability testing will then just be seeing if the patch has been applied (it already is in many cases, but keep on reading).  It opens the door to inconsistency if there is also a real CVE entry for the vulnerability (ies);  security scanner vendors who know which one it is will gain a +1 (+n) score for number of vulnerabilities scanned for every such occurrence they know about, without providing a better product.  

4. This accepts (original software) vendor say-so as gospel.  There are vendors that I don't trust to even say their own name without lying, and this CD effectively grants absolute trust in vendors.  

5. An important goal of the CVE is violated by this CD, inasmuch as the CVE is supposed to give a unique name to a vulnerability so that we know what we're talking about;  we still won't know what we're talking about after making a CVE entry for it.

I am all for letting system administrators know what they should take care of, but this would transform the CVE into a patch enumeration, not a vulnerability enumeration.  If a patch enumeration would be useful, perhaps it should be a separate list.

In conclusion, this CD exposes the CVE for attack and corruption.  The CVE should not become a sycophant of vendors (and of services that depend on it, in the name of system administrators).  If we don't know what we are talking about, what worth does the CVE offer?

regards,
Pascal 

At 3:58 PM -0500 2/17/02, Steven M. Christey wrote:
>This CD, while newly created, identifies and attempts to address an
>old problem.  Voting Editorial Board members will see references to
>CD:VAGUE in the "analysis" section of candidates that are affected by
>this CD.
>
>- Steve
>
>
>************************************************************************
>CD:VAGUE (Vague Vendor Descriptions of Vulnerabilities)
>************************************************************************
>Type: ABSTRACTION, INCLUSION
>Last updated: February 17, 2002
>
>CD:VAGUE is a CVE content decision that deals with cases in which
>vendors release security advisories or other types of alerts, but the
>descriptions contain fewer details than are needed by other CVE
>content decisions.
>
>CD:VAGUE is the only CVE content decision that can affect both
>inclusion (should an issue be included in CVE?) and abstraction (how
>do we distinguish between closely related issues?).
>
>Vague advisories or vulnerability reports have the following
>high-level impacts on CVE:
>
>- INCLUSION CDs: Some Editorial Board members believe that if a
>  problem is stated vaguely, it doesn't have enough information to
>  provide a useful description, so it doesn't "deserve" to be in CVE.
>
>- ABSTRACTION CDs: When a vulnerability description is vague, it can
>  be difficult to apply other CVE content decisions to determine (a)
>  whether the problem is a duplicate of an existing CVE candidate or
>  entry, and (b) what the proper level of abstraction is.
>
>In addition, the vague descriptions of the candidates increases the
>risk of mapping errors in CVE-compatible products, i.e. a
>CVE-compatible vendor may accidentally map an issue in their database
>to a CVE entry because the issue completely matches the entry's vague
>description.
>
>There are also occasional implications for vendor acknowledgement, and
>its impact on voting.  For example, a candidate for a detailed Bugtraq
>post may not get sufficient ACCEPT votes because Board members cannot
>replicate the problem, but there may be a different candidate with a
>vague advisory that addresses the reported problem.
>
>There is evidence that different vulnerability information sources
>(databases, alert summaries, etc.) use different approaches for
>deciding whether a vague advisory is addressing the same issue as an
>issue that was been reported in more detail elsewhere.
>
>CD:VAGUE, as with other content decisions, effectively provides a name
>for this difference across vulnerability data sources.
>
>
>DESCRIPTION
>-----------
>
>Following is the description for CD:VAGUE.
>
>1) If a vendor releases a vague report of a security problem, then
>   even though there is insufficient detail, the problem should be
>   included in CVE since (1) it is related to security (since the
>   vendor claims it is related to security), and (2) it is known to be
>   real (since the vendor reported it).
>
>2) Unless there is sufficient evidence that the vague advisory is
>   addressing the same issue as identified by another CVE item, it
>   should be distinguished from that item.
>
>
>RATIONALES
>----------
>
>INCLUSION:
>
>In several cases in the past, one or more Editorial Board members have
>voted to REJECT or at least REVIEW a candidate because its description
>was too vague, even when there was a vendor security advisory
>associated with it.
>
>However, the vendor is reporting on a problem that it believes has
>security implications, and that system administrators should take care
>of.  Also, someone malicious may discover it in the future, or already
>know about it.
>
>There is sufficient evidence that the problem is real, and the vendor
>believes that it has security implications.  Therefore it should be
>included in CVE.
>
>
>ABSTRACTION:
>
>It can be difficult to determine whether the vague advisory is a
>duplicate of an existing CVE candidate or entry, which may have more
>details.  Sometimes, the vague advisory is released months or
>sometimes years after more detailed reports have been reported.  If
>the advisory doesn't include information that (such as
>cross-references) that clearly links the issue to other CVE items,
>then it should be kept separated from the other CVE items, and the
>possible relationship should be noted.
>
>Also, when several closely related issues have been discovered before
>the vague advisory has been released, it is not clear whether the
>advisory addresses one, some, all, or none of the reported issues
>
>
>
>INCLUSION EXAMPLES
>------------------
>
>CAN-2001-1061 shows that a vendor has fixed a problem that the vendor
>claims is security-related, but there is insufficient information for
>understanding why the issue is related to security.
>
>  Candidate: CAN-2001-1061
>  URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-1061
>  Proposed: 20020131
>  Assigned: 20020131
>  Category: SF
>  Reference: AIXAPAR:IY22255
>  Reference: URL:http://archives.neohapsis.com/archives/aix/2001-q3/0003.html
>
>  Vulnerability in lsmcode in unknown versions of AIX, possibly
>  related to a usage error.
>
>  Analysis
>  ----------------
>  Vendor Acknowledgement: yes
>  Content Decisions: VAGUE
>
>  CD:VAGUE states that if a vendor releases a vague report of a security
>  problem, that even though there is insufficient detail, the problem
>  should be included in CVE.
>
>
>The full text for AIXAPAR:IY22255 says:
>
>  ABSTRACT: SECURITY: VULNERABILITY IN LSMCODE
>
>  PROBLEM DESCRIPTION:
>    The customer will not receive a usage error when
>    specifying an invalid type command line option for
>    lsmcode.
>
>  PROBLEM CONCLUSION:
>    Check the type provided from the command line. If the
>    type is not supported, then display a usage error.
>
>It's not clear from this description how the lack of a usage error
>implies a vulnerability.  However, IBM is saying that there's some
>sort of security problem.
>
>
>Here's another example candidate.
>
>======================================================
>Candidate: CAN-2000-0173
>URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0173
>Final-Decision:
>Interim-Decision:
>Modified:
>Proposed: 20000322
>Assigned: 20000322
>Category: SF
>Reference: SCO:SB-00.08a
>Reference: URL:ftp://ftp.sco.com/SSE/security_bulletins/SB-00.08a
>
>Vulnerability in the EELS system in SCO UnixWare 7.1.x allows remote
>attackers to cause a denial of service.
>
>INFERRED ACTION: CAN-2000-0173 SMC_REVIEW (3 accept, 2 review)
>
>Current Votes:
>   ACCEPT(2) Blake, Cole
>   MODIFY(1) Frech
>   NOOP(4) Ozancin, LeBlanc, Prosser, Wall
>   REVIEWING(2) Levy, Christey
>
>Voter Comments:
> Prosser> Although SCO is reporting the problem, there is too little info
>   available to make an informed decision.  Unable to find anything
>   anywhere on this.  It is an events logging system, so one would assume
>   that there is a way to fill up the log and cause a system halt, but no
>   way of confirming this with limited information.
> Christey> Perhaps we should create a content decision, say
>   CD:VAGUE-ACK, which says whether it's reasonable to
>   ACCEPT vendor-acknowledged problems that do not provide any
>   salient details, as in this candidate as well as several
>   others.
> Cole> I researched this a little more and you can change my NOOP to an
>   ACCEPT
> Frech> XF:sco-eels-dos
>
>
>
>ABSTRACTION EXAMPLES
>--------------------
>
>CAN-2001-0935 is a vague Linux advisory related to a problem in
>wu-ftpd.  See the Analysis section.
>
>  ======================================================
>  Candidate: CAN-2001-0935
>  Proposed: 20020131
>  Assigned: 20020131
>  Reference: SUSE:SuSE-SA:2001:043
>  Reference: URL:http://www.suse.de/de/support/security/2001_043_wuftpd_txt.html
>
>  Vulnerability in wu-ftpd 2.6.0, and possibly earlier versions, which
>  is unrelated to the ftpglob bug described in CAN-2001-0550.
>
>  Analysis
>  ----------------
>  Vendor Acknowledgement:
>  Content Decisions: SF-LOC, VAGUE
>
>  ABSTRACTION: The SUSE advisory describes the ftpglob buffer overflow
>  (CAN-2001-0550), then states "Some weeks ago, an internal source code
>  audit of wu-ftpd 2.6.0 performed by Thomas Biege, SuSE Security,
>  revealed some other security related bugs that are fixed."  It
>  provides no other details, so this problem should be distinguished.
>  There are no other details, so the CVE description is vague.
>
>  INCLUSION: CD:VAGUE suggests that when a vaguely worded advisory is
>  posted by a vendor, that it should still be included in CVE because
>  there is sufficient evidence that the problem is real (since it came
>  from the vendor).
>
>
>
>The following candidate is an example of a vague description that
>could apply to a number of potential products or vulnerabilities, some
>of which may already have CVE names.  In addition, other CVE content
>decisions cannot be properly applied.
>
>
>  ======================================================
>  Candidate: CAN-2001-0772
>  URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0772
>  Proposed: 20011012
>  Assigned: 20011012
>  Category: SF
>  Reference: HP:HPSBUX0105-151
>  Reference: URL:http://archives.neohapsis.com/archives/hp/2001-q2/0044.html
>  Reference: XF:hpux-cde-bo(6585)
>  Reference: URL:http://xforce.iss.net/static/6585.php
>
>  Buffer overflows and other vulnerabilities in multiple Common Desktop
>  Environment (CDE) modules in HP-UX 10.10 through 11.11 allow attackers
>  to cause a denial of service and possibly gain additional privileges.
>
>  Analysis
>  ----------------
>  Vendor Acknowledgement: yes advisory
>  Content Decisions: SF-EXEC, SF-LOC, VAGUE
>
>  ABSTRACTION/INCLUSION:
>  There has been a variety of vulnerabilities in CDE modules over the
>  years.  The HP advisory does not provide enough details to know if HP
>  is addressing known vulnerabilities or new ones.  Thus it is possible
>  that this item overlaps other CVE entries or candidates.
>  The advisory also implies that there are other types of problems
>  besides buffer overflows.  CD:SF-LOC would recommend creating separate
>  candidates for each problem, but since the advisory does not provide
>  details, it cannot be determined how many candidates should be
>  created.  Thus this candidate is clearly at a higher level of
>  abstraction than usual.
>
>
>  Current Votes:
>     ACCEPT(4) Baker, Foat, Cole, Frech
>     NOOP(2) Wall, Armstrong
>     REVIEWING(1) Christey
>
>  Voter Comments:
>   Christey> There is some overlap between CAN-2001-0551 and CAN-2001-0772.
>     CAN-2001-0551 describes a specific vulnerability in
>     dtprintinfo.  HP acknowledges CAN-2001-0551 by stating
>     that the problem is fixed in HP:HPSBUX0105-151, which
>     is CAN-2001-0772.  But CAN-2001-0772 is a vague advisory
>     that identifies other vulnerabilities (and vulnerability
>     types) besides CAN-2001-0551.  Perhaps CAN-2001-0772 should
>     be RECAST to "remove" the reference to dtprintinfo and
>     leave the other vague descriptions.  CAN-2001-0772 and
>     CAN-2001-0551 are very good examples of the problems that
>     CVE faces in being consistent with respect to the level of
>     abstraction, as documented in the CD:SF-CODEBASE, CD:SF-LOC,
>     and CD:VAGUE content decisions.

-- 
Pascal Meunier, Ph.D., M.Sc.
Assistant Research Scientist,
CERIAS
Purdue University