1117599 - CVE ID format change: CVE-\d{4}-\d{4} becomes CVE-\d{4}-\d{4,} this year

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Extensions, defect)

Description

[:glob ✱]

+++ This bug was initially created as a clone of Bug #1080600 +++

https://cve.mitre.org/cve/identifiers/syntaxchange.html

They haven't *yet* reached CVE-2014-10000, but if they don't, they promise to release a five-digit CVE at the beginning of 2015.

Interestingly,

"There is no limit on the number of arbitrary digits. Leading 0’s will only be used in IDs 1 to 999, as shown in column one below."

So these CVEs would need to match:

CVE-2014-0001 CVE-2014-9999
CVE-2014-10000 CVE-2014-99999
CVE-2014-100000 CVE-2014-999999
CVE-2014-1000000 CVE-2014-9999999

And these would be invalid:

CVE-2014-00001
CVE-2014-099999
CVE-2014-0123456

Which sounds more like this than my simplified subject:

CVE-\d{4}-(?:\d{4}|[1-9]\d{4,6})(?!\d)

(Reed Loden [:reed] from comment #5)

This is incorrect....

New CVE-ID Syntax

The new CVE-ID syntax is variable length and includes:

CVE prefix + Year + Arbitrary Digits


So, either CVE-\d{4}-(0\d{3}|[1-9]\d{3,}) or CVE-\d{4}-\d{4,}

Comment 1

[:Atoll]

:reed, could you provide a test case for a valid CVE id that would be mishandled by the original regex, but handled correctly by your replacement regex(es)?

Comment 2

[Reed Loden [:reed]]

(In reply to Richard Soderberg [:atoll] from comment #1)
> :reed, could you provide a test case for a valid CVE id that would be
> mishandled by the original regex, but handled correctly by your replacement
> regex(es)?

CVE-2014-9999999999999 is a valid CVE id that is mishandled by the original regex.

Comment 3

[:Atoll]

The regex from bug 1080600 ended up being:

> qr/(?<!\/|=)\b((?:CVE|CAN)-\d{4}-(?:\d{4}|[1-9]\d{4,6})(?!\d))\b/

so it seems like simply altering {4,6} to {4,} would be sufficient:

> qr/(?<!\/|=)\b((?:CVE|CAN)-\d{4}-(?:\d{4}|[1-9]\d{4,})(?!\d))\b/

Comment 4

[:Atoll]

Note that, from a practical standpoint, if {4,6} or {4,8} is more efficient than {4,}, I fully support going with a restricted parser that doesn't support more than a 10^6 CVEs in any given year, since we're currently at 10^4.

Comment 5

[Reed Loden [:reed]]

(In reply to Richard Soderberg [:atoll] from comment #4)
> Note that, from a practical standpoint, if {4,6} or {4,8} is more efficient
> than {4,}, I fully support going with a restricted parser that doesn't
> support more than a 10^6 CVEs in any given year, since we're currently at
> 10^4.

MITRE has made it clear that any parsing should support an arbitrary length of digits to the point that they may even assign a real issue to a high integer.

http://seclists.org/oss-sec/2015/q1/47

Comment 6

[:glob ✱]

thanks reed and atoll :)

-   match => qr/(?<!\/|=)\b((?:CVE|CAN)-\d{4}-(?:\d{4}|[1-9]\d{4,6})(?!\d))\b/,
+   match => qr/(?<!\/|=)\b((?:CVE|CAN)-\d{4}-(?:\d{4}|[1-9]\d{4,})(?!\d))\b/,

To ssh://[e-mail]/webtools/bmo/bugzilla.git
   7834fbf..50ae5be  master -> master