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

Re: CVE ID Issuance Strategies Using the New ID Syntax

My immediate feedback (without checking with other internal stakeholders at Cisco) is:

I think the first 999 entries should be used. As it is identical to practice in prior years there should be no problem for existing code. Only new, buggy code would be affected, but that shouldn't be enough reason to jump ahead 1000 entries and hasten the date for unfixed software to break. The onus should be on vendors with new code to test their code properly. Unless they put a high-school intern on this project, the parsing is not that complicated.

I like the idea of having a detection mechanism for broken software for a mere 2% penalty in lost CVE ID's. If someone issues or refers to CVE-2014-1000 (or anywhere else in the protected block) and it doesn't exist, that could flag a prewritten detection mechanism somewhere so they could be informed that their software is broken. And others could be warned not to blindly trust that source until they fix their code.


On Jun 18, 2013, at 1:36 PM, "Steven M. Christey" <coley@mitre.org>

> All,
> Now that the variable-length Option B has been selected, we are
> seeking the Board's input on several questions.  We are seeking the
> Board's assistance in communicating the syntax change, which will be
> covered in a separate thread.  This email regards the best strategy
> for issuing CVE IDs beginning with the "CVE-2014-" prefix, for the
> 2014-2015 transition year.
> For issuing CVE IDs, we see two significant questions:
> - whether we should avoid assignments of CVE-2014-0001 through
>  CVE-2014-0999 (avoiding any "leading zeroes")
> - whether issuance should reduce the risks in which 5-digit IDs might
>  be inadvertently truncated to 4-digit IDs ("truncation mitigation")
> --------------
> Beginning in 2014, should CVE IDs follow the practice of previous
> years and begin with CVE-2014-0001, or should they begin with
> CVE-2014-1000?
> Some Board members have suggested that we could avoid using leading
> 0's in CVE IDs, i.e., to start with "CVE-2014-1000" instead of
> "CVE-2014-0001".  This approach might simplify some code that outputs
> CVE IDs.  We have observed third-party code that represents
> "CVE-2013-0123" not as a string, but as two integer column values:
> 2013 and 123. However, it is not clear whether our requirement of
> leading zeroes on output poses any significant technical cost.
> Besides the possible implementation costs for some parties, are there
> any other benefits to avoiding leading zeroes?
> Starting with CVE-2014-1000 would reduce the space by 999 IDs before 5
> digits are needed, which would reduce the amount of time that vendors
> have to fix their implementations, possibly by a couple of months.
> MITRE recommends continuing the practice of the past 14 years, and
> using the leading zeroes for only the first 999 IDs.
> ---------------------
> For 2014, should our issuance strategy mitigate the potential risks
> when CVE IDs with 5 or more digits are issued, but the IDs are not
> properly handled by non-compliant implementations that assume only 4
> digits?
> If a legitimate 5-digit ID is inadvertently truncated to a 4-digit ID,
> then this would cause incorrect CVE IDs to be used and adversely
> affect the exchange of vulnerability information.  For example,
> suppose that both CVE-2014-1000 and CVE-2014-10007 are issued in 2014,
> and an advisory refers to CVE-2014-10007.  An implementation that
> assumes 4 digits might inadvertently convert CVE-2014-10007 into
> CVE-2014-1000, which would be a completely different ID for a
> different vulnerability.
> Even if our communication strategy is highly successful, there is
> still a risk that either (1) some developers will not learn about the
> ID syntax change, or (2) some developers will not be able to fix their
> code in time.  Based on some research we conducted earlier this year,
> we have seen a number of CVE-ID implementations in which 4 digits are
> assumed.  The 4-digit assumption might be most prominent in code that
> (1) extracts or parses CVE IDs, or (2) outputs CVEs assuming a
> specific format or length.
> To minimize this risk, during 2014 only, we could avoid assigning a
> relatively small number of 4-digit IDs if there is a reasonable chance
> that a different, 5-digit ID could be assigned that has a risk of
> being inadvertently truncated to the original 4-digit ID.  For
> example, the first 5-digit ID to be issued would be CVE-2014-10000;
> since this could be truncated to CVE-2014-1000, we could avoid
> assigning CVE-2014-1000 entirely.  We could use this approach for a
> "protecting block" of IDs, such as CVE-2014-1000 through CVE-2014-1199
> (200 IDs).  This means that any 4-digit truncation of CVE-2014-10000
> through CVE-2014-11999 would not map to a valid ID.  Since the block
> of 2000 "protected" 5-digit IDs will almost certainly include IDs for
> high-profile vulnerabilities, users and developers of truncating
> implementations are likely to be alerted to the problem quickly.
> Also, the CVE-2014-1000 to CVE-2014-1199 protecting block is small
> enough (200 IDs) that it would make a negligible difference (2%) in
> the likelihood of reaching 10,000 IDs in 2014. Thus, there is an
> attractive 10-to-1 tradeoff between the number of protected IDs and
> the size of the protecting block.  Our only known disadvantage is that
> reaching CVE-2014-10000 even 2% faster might adversely affect someone.
> The exact size and implementation of the protecting block would be
> determined later.  If truncation mitigation is desired, then some
> potential ways to implement protecting blocks include, but are not
> necessarily limited to, (1) not assigning the protecting block IDs
> (e.g. CVE-2014-1000) at all, or (2) assigning protecting block IDs,
> but providing a description that emphasizes that the ID is not for
> public use and might indicate a truncation error.
> At this time, MITRE does not have a specific recommendation regarding
> whether truncation mitigation should be pursued, and we welcome
> opinions from the Board.
> We would appreciate everybody's feedback on these questions.
> Regards,
> The MITRE CVE Team

Page Last Updated: June 26, 2013