CVE-ID Syntax Changing on January 1, 2014 — learn more
2006-02-16 What is the state of vulnerability research?
Seven open questions to vulnerability researchers, posted on Bugtraq, intended to encourage fruitful public discussion on the topic.
2006-02-14 [Full-disclosure] On the "0-day" term
Comments addressing the "Internet Explorer drag&drop 0day" thread that was posted on the Full-Disclosure discussion list.
A discussion on the Vulnerability Information Managers (VIM) mailing list of how the number of errors in input validation is increasing.
2006-02-10 [VIM] context-dependent attackers
A brief explanation of "context-dependent" attackers posted on the Vulnerability Information Managers (VIM) mailing list.
A discussion of how each time a blacklist defense is modified a new variant is found that works around the more restrictive blacklist.
A short paper on how to interpret vulnerability statistics. Includes a discussion about the veracity of publicly available Refined Vulnerability Information (RVI) sources.
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.
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
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
"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.