[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Mar 2016 11:24:44 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: cve-editorial-board-list <cve-editorial-board-list@...ts.mitre.org>,
oss-security <oss-security@...ts.openwall.com>
Subject: Concerns about CVE coverage shrinking - direct impact to researchers/companies
So I've now heard from several security researchers that they are unable to
get CVEs for issues that need CVEs (e.g. widely used hardware/software with
flaws that have real world impacts and need to be properly tracked. This
has definitely resulted in issues being publicized with no CVE that then
makes it much harder to track and deal with these issues.
I'm also worryingly hearing about people that may have given up asking for
CVEs and publicizing their work at all, but of course cannot easily confirm
this as I don't have any access on insight into what cve-assign@...re.org
is actually doing/who they are talking to.
I finally was able to get a researcher willing to "go on the record" as it
were, with thanks to Hanno Böck for stepping up.
My main concern is this, if this tiered coverage (
https://cve.mitre.org/cve/data_sources_product_coverage.html) is the new
way forwards we will have significantly less CVE coverage in a time where
security issues are literally exploding and becoming much more of a problem
leading to a situation where I fear that CVE will not be as useful anymore.
As CVE is the cornerstone of our industry for identifying vulnerabilities
and making it much easier to track and search for them I think it's
critical that we re-examine this tier'ed coverage policy that Mitre
arbitrarily decided to enact (there was a brief discussion at
https://cve.mitre.org/data/board/archives/2016-01/msg00015.html with some
concerns raised and not really addressed).
---------- Forwarded message ----------
From: Hanno Böck <hanno@...eck.de>
Date: Fri, Mar 4, 2016 at 10:35 AM
Subject: Fw: CVE request: nonce reuse in GCM implementation of Radware Load
balancers
To: Kurt Seifried <kseifried@...hat.com>
This was the issue I requested a CVE for:
https://kb.radware.com/Questions/SecurityAdvisory/Public/Security-Advisory-Explicit-Initialization-Vector-f
(And currently I'd apprechiate if you don't make a big buzz out of this
issue, because we're preparing a paper on it by the end of march where
we'll disclose a bunch of similar issues)
Begin forwarded message:
Date: Thu, 11 Feb 2016 02:58:06 +0000
From: CVE ID Requests <cve-assign@...re.org>
To: Hanno Böck <hanno@...eck.de>
Cc: CVE ID Requests <cve-assign@...re.org>
Subject: RE: CVE request: nonce reuse in GCM implementation of Radware
Load balancers
Thank you for your request.
Your request is outside the scope of CVE's published priorities. As
such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at
this time.
CVE-ID assignments are made according to the priorities published at
http://cve.mitre.org/cve/data_sources_product_coverage.html. Processing
of CVE-ID requests for non-prioritized products can occur at any time,
but the CVE-ID assignments may be delayed.
If you feel that our assessment is in error, or that the product or
products in question should be included within the CVE published
priorities, please provide MITRE with your justification(s).
--
CVE assignment team, MITRE CVE Numbering Authority M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
--
Hanno Böck
https://hboeck.de/
mail/jabber: hanno@...eck.de
GPG: BBB51E42
--
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com
Content of type "text/html" skipped
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
