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

["Frech, Andre (ISSAtlanta)" <AFrech@iss.net>]

The first thing that came to my mind while reading the CD:VAGUE
specification was "consider the source." I have no problems when the
vendor reports (even vague) issues with their systems. I doubt a
vendor would be reporting problems that didn't exist, at least in
their own systems.

However, there are several pending items in CVE that are only
cross-referenced by security tool references, or no references at
all. Some of the latter category we have located in our database as
items in competitor's scanning features, or (worse yet)
unconfirmed/unreferenced issues that have been picked up by the SANS
Top 20 list. I don't know if these items can be rounded up into
CD:VAGUE or if there is another content decision affecting them, but
there seem to be enough of them to define a CD:VAGUE EXCLUSION type.

Andre
---
Andre Frech
X-Force Research Engineer
Internet Security Systems (ISS)
6303 Barfield Road
Atlanta, Georgia 30328-4233
Phone: 404-236-2927
Fax: 404-236-2624

Internet Security Systems -- The Power to Protect


> -----Original Message-----
> From: Steven M. Christey [mailto:coley@linus.mitre.org]
> Sent: Sunday, February 17, 2002 3:59 PM
> To: cve-editorial-board-list@lists.mitre.org
> Subject: [TECH] CD:VAGUE (Vague Vendor Descriptions of
> Vulnerabilities)
>
>
> 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.