2015-03-20 Update on Turnaround Times for CVE-Assign Requests

Discusses recent issues experienced when making requests for CVE IDs to the cve-assign email address, including process changes being made to improve response times.

2015-01-13 CVE IDs Posted Today for the First Time Using the New ID Syntax

Today we posted the first-ever CVE IDs using the new ID syntax. The first usable 5-digit CVE ID was CVE-2014-10001, and the first usable 6-digit CVE ID was CVE-2014-100001.

All together there were a total of 92 IDs with 4 digits in the CVE downloads, 48 with 5 digits, and 44 with 6 digits. Some of those are RESERVED or REJECTED. We have over 70 usable entries. CVE-2014-10001 through CVE-2014-10039, and CVE-2014-100001 through CVE-2014-100038 all identify vulnerabilities disclosed in 2014. Some IDs were REJECTed because they are commonly used as examples. Some IDs are RESERVED so that consumers can verify their ability to process reserved data. CVE-2014-10042 and CVE-2014-100040 will remain as RESERVED for the foreseeable future.

Please report any problems, or anticipated problems, that you encounter with CVE IDs issued in the new format to cve-id-change@mitre.org.

ADDITIONAL INFORMATION:

* CVE ID Syntax Change - https://cve.mitre.org/cve/identifiers/syntaxchange.html
* Technical Guidance for Handling the New CVE ID Syntax - https://cve.mitre.org/cve/identifiers/tech-guidance.html

2013-03-20 "Context-dependent" and "User-assisted" Terminology in CVE

A discussion of how the CVE Content Team uses the following terms in the descriptions portion of CVE Identifiers: "Context-dependent," "User-assisted," and "Physically Proximate." CVE examples are also included for each term.

2013-03-12 CVE and "weak" crypto

An informal response to a request for a CVE ID for an "MD5 used for Download verification" explaining that for CVE, our default position is that "using MD5 for integrity checking of downloads" is a security-hardening issue, and thus should NOT receive a CVE ID.

2013-03-08 CVE abstraction choices and the Linux kernel

A discussion of CVE abstraction choices and the Linux kernel that might significantly impact how CVE assignment occurs in the future.

2013-02-21 CVE Guidance for Libraries and Resource-Consumption DoS

A response to recent discussions about XXE and related issues that have touched upon a number of issues that must be considered for CVE assignment.

2006-02-24 Day in the Life: Will the real SUSE-SA:2006:010 please stand up!

Looking at this Bugtraq post, we see the SuSE advisory "SUSE-SA:2006:010" is for two issues in Heimdal:

BUGTRAQ:20060224 SuSE Security Announcement: heimdal (SUSE-SA:2006:010) http://www.securityfocus.com/archive/1/archive/1/425979/100/0/threaded

But if you go to Novell’s advisory page, you get this URL: http://www.novell.com/linux/security/advisories/2006_10_casa.html, which is about something called CASA, not Heimdal.

Why does CVE care? SuSE is likely going to post a correction at some point, with a fixed advisory name. We don’t know which issue "SUSE-SA:2006:010" really applies to, so we can’t add it as a reference yet.

I have an inquiry into SuSE to resolve and will post an update one I hear back.

2006-02-23 "Local File Inclusion" or a "Traversal Arbitrary File Access"?

> http://[target]/blah.php?variable=
../../../../../../../etc/passwd%00
> Is this a "local file inclusion" or a 
"traversal arbitrary file access", and why?

I call it a traversal issue that just happens to involve an include/require statement. Underlying bug is ".." so that’s why I say traversal. However, if it accepts a remote URL, then it’s remote file include. So, in CVE parlance at this moment, there’s no such thing as "local file include" — at least we don’t use that term.

But this puts things in an unenviable position where the bug type is entirely dependent on whether allow_fopen_urls is enabled or not... which instinctively tells me something is wrong with how I’m doing it. Plus, sometimes I can’t know which term to use if the disclosure is not comprehensive.

Another rationale I fall back on is this: "would stripping out ‘..’ sequences fix the remote file include vector?" and the answer is no... so there are 2 separate aspects to this.

This whole include business seems to be little different to me than an insecure open() call in a Perl program — directory traversal, PLUS shell metacharacters... A language has over-loaded functionality, so serves it right when apps have multiple vulnerabilities in the same line of code.

2006-01-10 Managing a Candidate Request for a New Issue

Just received an incoming candidate request from two different Linux distributions, for a product with an independent developer. This request is fairly common — the issue was published today and they wanted a candidate for it ASAP. When an issue becomes public, the Linux vendors know to ask CVE to reduce the risk of duplicate assignments.

In this case, the original vulnerability report from the product’s developer credited a researcher who usually reserves candidates from us. No advisory from that researcher yet.

The developer did not include a candidate.

A quick glance at my records — nothing out there for this particular researcher, although they did reserve some candidates a month or two ago. Maybe they gave the candidate to this vendor, maybe they used it for a completely different issue.

Phone call to the researcher — nope, he’s not in.

So, what to do?

I created a new candidate (already refined from a content team member), notified the researcher of this change (just in case), and sent the candidate on to the vendors who requested it.

This is typical of the kind of interactions I regularly conduct as a CNA.

2005-06-29 Handling Duplicate Public CVE Identifiers

Introduction

As more vendors, researchers, and coordinators use CVE identifiers in initial public vulnerability announcements, the risk of multiple assignments of the same CVE identifier increases. While all involved parties should coordinate on the CVE name for an issue, errors still occur, especially if one party does not normally use CVE.

When duplicate identifiers are made public, the Primary CNA — i.e., MITRE — must be consulted to specially choose the proper candidate to use.

Criteria for Selecting the Preferred Identifier

MITRE uses the following criteria to select which identifier will be associated with the issue.

The criteria are roughly prioritized, but they are still evolving.

1) PREFER THE MOST COMMONLY REFERENCED IDENTIFIER. This is roughly gauged by searching for all affected identifiers on a search engine and comparing results.

2) If the usage numbers of identifiers are about the same, then CHOOSE THE IDENTIFIER USED BY THE MOST AUTHORITATIVE SOURCE. The "most authoritative source" is roughly prioritized as: vendor, coordinator, researcher.

3) If the identifiers have the same level of authority, then CHOOSE THE IDENTIFIER THAT HAS BEEN PUBLIC FOR THE LONGEST PERIOD OF TIME.

4) If the identifiers have been public for the same amount of time, then CHOOSE THE IDENTIFIER WITH THE SMALLEST NUMERIC PORTION.

Annotating Duplicate Identifiers

Once the preferred identifier has been selected by MITRE, MITRE will modify the descriptions of all other identifiers and reference the preferred identifier.

2005-03-23 CVE Content Decisions in Action

User Question:

"CAN-2005-0527 was issued a month or so ago to address an issue in Firefox known as firescrolling, discovered by Michael Krax. According to a recent post by him at http://mikx.de/firescrolling2/ the issue was not properly addressed by version 1.0.1 of Firefox, which was supposed to address the issue. Mozilla released version 1.0.2 of Firefox today to address, amongst other things, this issue. It appears that a new CAN was issued for this fix (CAN-2005-0401). My question is as follows, since the new fix is reportedly addressing the exact some issue, but properly addressing it this time, isn’t there no need for a new CAN?"

CVE Editor’s Response:

Over the past couple years we’ve tried to be more precise about cases of incomplete or partial fixes. As you probably know, many times vendors will slap on a patch for a single attack vector without necessarily fixing the entire underlying issue. If we use the same CAN for the "broken" versus the "new" patch, then vulnerability information consumers who think they’ve addressed the original vulnerability may be incorrect.

This practical implication is really an outgrowth of CVE’s content decisions, which say to SPLIT two issues if issue 1 appears in some version that issue 2 does not. In the firescrolling case, Mozilla first fixed "one of the key bugs" according to Michael Krax, but another bug remained. These are then regarded as variants — albeit very similar ones — from the CVE perspective, since the initial firescrolling "one of the key bugs" appears in FireFox 1.0 but *not* 1.0.1, whereas firescrolling2 appears in 1.0.1.