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

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

I would be happy if entries made for the sake of exhaustiveness only, even if we know little or nothing about the underlying vulnerabilities, were clearly marked as being of lower quality.  The disclaimer should be at least as apparent as the one for candidates.   Perhaps they should even carry a specific tag in their name, like CAN and CVE, such as "???", which explicitly carries the uncertainty about what they mean.

I would also volunteer to count the number of "???" entries for each vendor, which would be helpful to gauge the level of obfuscation they perform.

Cheers,
Pascal

At 7:29 PM -0500 2/17/02, Steven M. Christey wrote:
>Pascal Meunier asked:
>
>>Is this item open for discussion or not?
>
>It's a new content decision, so it's open for discussion :-) Any CVE
>candidate that has been labeled with CD:VAGUE will remain a candidate
>until this topic has been discussed sufficiently.
>
>>I see this as a change in the focus of the CVE from vulnerabilities to
>>patches and a kind of Pandora's box.
>
>I see it as a recognition that we're already in a Pandora's box.
>
>I'll have to look more closely at the write-up for CD:VAGUE, but the
>focus of CD:VAGUE is when a vendor says that there's a security
>problem.  This isn't intended to apply to generic patches.  Even if
>there's not any good information for *understanding* the
>vulnerability, the intention of CD:VAGUE is to capture cases where it
>is known that there is *some* vulnerability.
>
>>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".
>
>There are *real* advisories that already do this.  Sometimes they
>don't even say how serious the problem is, or whether it's locally or
>remotely exploitable.
>
>Some good examples can be found in HP security advisories, SCO
>advisories (including the more recent ones since Caldera acquired
>SCO), old Red Hat errata, some Netscape advisories, most CERT
>advisories from 1993 and earlier, and a variety of others.  There
>might be a BIND vulnerability that affects 8.2.5 and earlier, contrary
>to popular understanding that 8.2.3 has no vulnerabilities.  But it's
>very difficult to tell from the ISC web site.  Does the fact that, in
>one place, ISC says "8.2.5 and earlier has a security problem" matter
>to people who care about vulnerabilities, or that in a different
>place, they say "8.3.0 has a DoS problem"?  I think so.
>
>Some of the more complicated legacy issues that still don't have
>candidates are directly related to vague advisories.  We don't know
>which CVE to map the advisory to.
>
>A more difficult example is that CVE's data sources seem to be getting
>better at scanning regular bug reports for security fixes.  It appears
>that these issues have gone unnoticed in the past because they weren't
>posted to *Bugtraq or listed in a major advisory.
>
>>Do you want to create a CVE entry for [an extremely vague security
>>report]?
>
>Some Board members have said not to create CVE entries for vaguely
>reported issues.  But should a vulnerability scanner tell a system
>administrator that they haven't installed a patch that has been
>specifically labeled as security-related, by the vendor?
>
>Vague advisories make things difficult for certain types of analysis -
>including CVE - but I suspect that many consumers of vulnerability
>information would rather have a CVE name for *some* vulnerability,
>rather than no CVE name at all.  CVE would not directly run across
>vague advisories if our data sources didn't think it was important to
>report them.
>
>>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.
>
>This inconsistency will exist regardless of how CVE approaches it.
>Vulnerability databases and system administrators already have to
>decide whether Vague Advisory X is really describing issue 1, issue 2,
>or a previously unknown issue.  CD:VAGUE gives a label to places where
>there may be inconsistency.
>
>The opposite could also be true: if we roll a vague advisory into a
>CVE candidate just because it "looks right," then we run the risk of
>having scanners think that they're checking for one vulnerability,
>when they should be checking for two.
>
>The way around this is to work directly with the vendors who provide
>vague advisories to try and get some clarity.  But I suspect that
>there will be some vendors who might not want to say "my advisory X is
>linked to CVE Y" if CVE Y happens to include a reference to certain
>details that the vendor doesn't want publicized.
>
>MITRE also has to deal with vague advisories when determining vendor
>acknowledgement.  "security fix" in a changelog does not mean that the
>vendor has acknowledged the specific problem that has been reported.
>CVE voters may have noticed that there are a lot more "unknown vague"
>values in the acknowledgement field of candidates; this reflects a
>growing awareness on our part that sometimes, certain assumptions are
>made that don't seem to have enough supporting facts.
>
>>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.
>
>This CD says that if a vendor claims that there's a vulnerability in
>their product, that we should trust them.  We can accept CVE
>candidates without vendor acknowledgement - we just need enough votes.
>
>However, vendors could try to be more vague about the issues in their
>products in the hope that they get 1 candidate instead of multiple
>candidates.  I see that this could become a problem if it becomes
>economically important for vendors to minimize the number of CVE's
>that appear in their products.  On the other hand, if they refuse to
>provide any details, there could be external pressures on them to be
>more forthcoming.  Vendors might decide to go this route regardless of
>what CVE does.
>
>>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.
>
>This is an interesting thematic argument.  But the fact is that we
>DON'T always know what we're talking about.  Nobody does.  (If they
>do, please nominate them to the Editorial Board ;-)
>
>Whether we ignore a vague advisory, try to merge it with other issues
>in a possibly incorrect manner, or create a separate item for it, we
>won't know what we're talking about without close vendor cooperation
>or some serious reverse engineering, which is resource-intensive.  And
>that gets right back to the whole disclosure thing, which CVE can't
>solve.
>
>Interesting points... sigh, when will this be easy?? ;-) ;-)
>
>Other feedback welcome and appreciated.  I thought that this would be
>a CD that everyone could live with :-)
>
>- Steve

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