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

["Steven M. Christey" <coley@linus.mitre.org>]

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