navigation bar left navigation bar right

Secunia CSI7
navigation left tab About us navigation right tab
navigation left tab Careers navigation right tab
navigation left tab Memberships navigation right tab
navigation left tab Newsroom navigation right tab
navigation left tab Contact us navigation right tab
Blog
News
Articles

Real-World Problems of CVE Assignment

Get this blog as an RSS Feed
11:10 CET on the 23rd August 2011
Entry written by Carsten Eiram.

Brad Arkin, Senior Director of Product Security and Privacy at Adobe, recently posted a blog describing the problems of CVE assignment and explaining the policy used by Adobe. This blog post is a response with my concerns on how software vendors apply their own rules for assigning CVE identifiers and also seem to exploit the wording of the purpose of CVE to issue silent fixes.

In the blog post, Brad Arkin points out that there are, unfortunately, "many differences in opinion on how CVEs should be used in real-world situations". I completely agree with this statement and have personally had many discussions with a number of companies, including Adobe, regarding incorrect assignment of CVE identifiers. On that note, I am overall pleased that Adobe has made some improvements in this area.

It is, however, important to observe that while there may be different opinions on how CVEs should be assigned, then CVE is a standard with guidelines and abstraction rules. These are the ones that matter. Software vendors and CNAs cannot just decide on their own rules. My views on CVE assignment are slightly different to MITRE's, but I follow the guidelines when assigning CVEs as part of Secunia's duty as a CNA just like everyone else should. Of course, should a CNA, software vendor, researcher, or anyone else have suggestions on how to improve the abstraction rules and ease general real-world use, such suggestions are more than welcomed by the CVE Editorial Board, who will then decide on any changes that should be made to ensure everyone follows the same standard.

When Adobe elaborates on the rules used internally to assign CVE identifiers, I especially noted the third rule, which lists that: "Any bug identified by Adobe engineers and resolved as part of the Adobe Secure Product Lifecycle (SPLC) is not assigned a CVE". This also applies to bugs (vulnerabilities) discovered by: "consultants, contractors or partners as part of their joint engineering effort/work with Adobe". The basis for this argument is that Adobe does not consider such vulnerabilities "publicly known" with a reference to the CVE description, which states that "CVE is a dictionary of publicly known information security vulnerabilities and exposures".

Naturally, CVE identifiers are assigned for publicly known vulnerabilities - how should they be assigned for vulnerabilities we do not know exist? However, I find it ludicrous that the wording of CVE's purpose almost seems to be misused as an excuse for software vendors to silently fix internally discovered vulnerabilities and not assign CVEs. I have previously seen Microsoft offer a similar explanation in attempt to argue for silently fixed vulnerabilities (or "variants" as they call them).

A software vendor should never silently fix vulnerabilities regardless of these being internally discovered or not; it is unethical and a disservice to customers. Vulnerability fixes should be clearly listed and, as such, become public and should be assigned a CVE identifier. Any public vulnerability should be assigned a CVE and all vulnerabilities should be made public.

It is important to also note that if MITRE becomes aware of a vendor having silently fixed a vulnerability not covered by a CVE, then one will be assigned even though no vulnerability details are available. This fact debunks the statement that there is no need for a software vendor to assign a CVE for an internally discovered vulnerability or similar.

In the specific case of Google's recent heavy fuzzing run against Flash Player, Adobe originally did not assign CVE identifiers nor list the vulnerabilities as they "viewed this testing as part of the SPLC that spans the joint engineering efforts with the Google Chrome team". Later, a single CVE identifier was assigned to cover all the vulnerabilities, but Google clearly state that they noticed various vulnerability classes including "buffer overflows, integer overflows, use-after-frees and object type confusions"; assigning a single CVE identifier, therefore, goes against the abstraction rules. Yes, it may be time consuming for a software vendor to go back and check the change logs to determine what exactly was fixed in order to properly assign CVE identifiers, but consider that an encouragement to in the future get it right from the beginning instead of silently addressing the issues and not assigning CVEs.

Lastly, all the questions asked in the first paragraph of Adobe's blog post are clearly answered by the CVE abstraction rules, which Adobe as a CNA should be familiar with. Should they, however, have any questions then I am, as a member of the CVE Editorial Board, happy to answer these.

Stay Secure,

Carsten Eiram
Chief Security Specialist

Discuss this blog entry
A new thread in our forum is created. Activate the thread by commenting/discussing below.
Subject: Real-World Problems of CVE Assignment
 
No posts yet

-

You must be logged in to post a comment.



 Products Solutions Customers Partner Resources Company
 
 Corporate
Vulnerability Intelligence Manager (VIM)
Corporate Software Inspector (CSI)
Consumer
Personal Software Inspector (PSI)
Online Software Inspector (OSI)
 Industry
Compliance
Technology
Integration
 Customers
Testimonials
 MSSP
Technology Partners
References
 Reports
Webinars
Events
 About us
Careers
Memberships
Newsroom


Secunia is a member of FIRST Secunia is a member of EDUcause Secunia is a member of The Open Group Secunia is a member of FS-ISAC
 
Secunia © 2002-2014 Secunia ApS - Rued Langgaards Vej 8, 4th floor, DK-2300 Copenhagen, Denmark - +45 7020 5144
Terms & Conditions and Copyright - Privacy - Report Vulnerability - Disclaimer
follow Secunia on Facebook follow Secunia on Twitter follow Secunia on LinkedIn follow Secunia on YouTube follow Secunia Xing follow Secunias RSS feed follow Secunia on Google+