Re: Use of CAN/CVE numbers

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

Russ Cooper said:

>1. MS02-038 Security Bulletin from Microsoft refers, incorrectly, to
>   several CAN/CVE numbers. First, in the placemark link to the
>   description of the vulnerabilities they use CAN-2001-0644 and
>   CAN-2001-0645. In fact, they should be CAN-2002-0644 and
>   CAN-2002-0645.

Thanks for noticing this, I'll notify Microsoft.

>3. When Dave Aitel published his NASL script for his new MS SQL Server
>   BO on Bugtraq, he included the following;
>
>># script_cve_id("CVE-2000-0402");
>
>which references a saved admin password during MS SQL Server
>installation, nothing to do with his new BO.

The # is a NASL comment, so at least it's commented out, but there is
the implication that it's the same CVE.  Maybe it's a cut-and-paste
from an earlier NASL script.

>I would suggest that there may be a requirement to put fields into the
>CVE which note the fact that incorrect references to a CAN/CVE number
>were in public, and possibly point to the correct entries.

The "analysis" field would be a useful place for this.  It's not quite
public yet (non-Board members can only see it through the proposal
ballots in the mail archives), but we plan to publish the analysis
field at the same time the content decision fields are published.

>I only point this out because both of these documents will be
>artifacts now, incorrectly referencing CVE information.

Unfortunately, there have been other cases besides the ones that you
described above.  For example, today's WS_FTP release by @stake
included both CAN-2002-0826 (the correct number) and CAN-2002-0926
(incorrect).  An earlier Microsoft typo in MS02-021 pointed to
CAN-2002-1056 (which didn't exist) instead of CAN-2002-0156.  (So now
we have a CVE-2002-1056 when the next-earliest CAN is in the -0800
range).  In an advisory for multiple vulnerabilities, Matt Moore
switched the meaning of one candidate with another, in comparison to
how Microsoft assigned the issue.  This "switch" also happened in a
CERT advisory (that one was my fault).

I have modified the candidate reservation recommendations to tell
people to be careful about typos and multiple issues.  However, these
types of mistakes may happen more frequently as more and more
candidates are distributed to CNA's.  One solution may be to watch
closely for these mistakes and, if an entity makes these mistakes too
frequently, they could be prevented from getting reserved CANs.

To the others on this list whose own identifiers are commonly
referenced in other people's advisories - how do you deal with their
typos and similar errors?

- Steve