[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Public use of CVE IDs within the ID-Syntax Protection Block

All,

Recently, some CVE IDs within the protection block have been publicly
referenced, which is causing some confusion.  This message is intended
to explain the circumstances that contributed to the confusion, and
how I mean to resolve it.

As posted to the Editorial Board on January 2014 last year [1], and as
publicized on the CVE web site for approximately the same amount of
time [2], we implemented a "protection block" for handling potential
truncation errors in the case of 5-digit CVE IDs.  The protection
block covers IDs between CVE-2014-1000 and CVE-2014-1200, inclusive.
These IDs are not allocated to anybody.

The protection block was implemented as an intentional gap in the
CVE-ID space by excluding the entries from CVE entirely - not even
with RESERVED or REJECT disclaimers.  The entries are not even listed
in CVE downloads.  The intention is to trigger fatal errors when
people attempt to look up a CVE-ID that does not exist; a truncation
of CVE-2014-10000 to CVE-2014-1000, for example, can indirectly alert
users about a problem when they fail to find CVE-2014-1000.

This was intentionally-planned functionality, as documented on the
technical guidance page since early 2014:

    Because those IDs do not exist at all, any inadvertent usage will
    likely generate a noticeable error in a CVE-using implementation,
    which might alert the user (and vendor) to the possible truncation.

Unfortunately, we now have a case in which the protection block
"worked."  It triggered surprising errors that were noticed by
consumers - but the errors were not due to inadvertent truncation.

The situation arose as follows:

1. For some reason we don't yet know, a particular researcher has been
    making a small number of disclosures that list CVE IDs within the
    protection block, such as CVE-2014-1137.  Needless to say, these
    IDs were not assigned to the researcher, who has also made
    incorrect mappings to legitimate IDs for unrelated issues.

    This public usage of protected IDs is the trigger for the resulting
    confusion.

2. Whenever there is an attempt to access a protected ID on
    cve.mitre.org, we have a custom CVE page that explains the
    protection block, such as:

      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1137

    This custom error page is intended to alert the user about the
    protection block.

3. In this case, since the CVE was in the protection block, it
    generated the custom error page about truncation - yet, the usage
    of CVE-2014-1137 was not due to truncation.

4. As this situation developed (with a small number of disclosures), I
    asked CVE content team members to create a separate CVE identifier
    - the official entry - and to use the incorrect ID as a keyword,
    which could help to find the appropriate ID when the entries are
    updated on the CVE web site.  However, we did not populate the
    protection-block ID with an associated "** REJECT **" statement,
    and we did not reference it in the official ID.  For example, a
    public-seeming ID (CVE-2014-1137) could not be not found at all,
    while its apparent duplicate (CVE-2014-9445) was published without
    mentioning CVE-2014-1137 at all.  In retrospect, this was a
    mistake.

5. The publication of the official "duplicate" ID caused confusion at
    OSVDB, and likely elsewhere.  For OSVDB, they used "grep" on raw
    CVE downloads to find the protected ID, and of course this search
    failed.  However, the person doing the analysis apparently did not
    consider that the ID was within the protection block.

6. Further exacerbating the problem is the timing of this situation,
    when we are literally days away from issuing 5-digit and 6-digit
    IDs, where the protection block is more likely to serve its
    intended purpose of alerting users and vendors who have errors in
    their CVE-ID management.  In this situation, the protection-block
    message was a red herring.

Interestingly, CVE-ID typos and even 5-digit IDs have been mistakenly
referenced in the past year, which has led to non-existent CVE entries
that should have been noticed in a similar fashion; yet, apparently,
these did not cause any trouble or confusion.  So, it must be the use
of an ID within the protection block that contributed to significant
confusion this time.

Moving forward, the current plan is:

1. We have already attempted to contact the researcher to get them on
    the right track about CVE assignment.

2. We will create REJECTed entries for the protected IDs being
    referenced.  This will happen today.

3. We will change the text of the error messages to better emphasize
    the protection block while allowing for other situations such as
    typos.  I plan to do this in the upcoming days.

4. For any official, MITRE-assigned CVE-ID, we will consider adding a
    NOTE statement to reference the self-assigned ID.

I hope this explains the situation sufficiently.

- Steve

References:

[1] http://cve.mitre.org/data/board/archives/2014-01/msg00000.html

[2] http://cve.mitre.org/cve/identifiers/tech-guidance.html#extraction_or_parsing
Page Last Updated or Reviewed: October 30, 2015