[LACNIC/Seguridad] Real-World Problems of CVE Assignment

[Fernando Gont]

Estimados,

Les dejo un post del blog de Secunia, sobre un tema mas que
interesante/frustrante.

Fuente: http://secunia.com/blog/248

---- cut here ----
Real-World Problems of CVE Assignment
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
---- cut here ----

-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
web: http://www.si6networks.com