At the last Editorial Board meeting, there was a desire to include the entire Editorial Board in a discussion focused on reviewing the current set of expectations and guidelines describing a well-formed CVE request and CVE. This discussion started as part of the discussions happening within the DWF pilot.
The current guidelines are included in this document on Github:
What works well in this document?
What information is missing or problematic?
Is it too long? Is there a better format for the presentation that you think would work better?
Is it addressing the right audience?
Thanks for your assistance!
The CVE Team
On Tue, May 10, 2016 at 9:41 AM, Common Vulnerabilities & Exposures <[hidden email]> wrote:
So for the DWF handling of Open Source vulnerabilities my plan is currently for the general case:
Minimum required for CVE:
-Software name (and/or URL if it's a common name used more than once)
-Vulnerable version (one or more)
-Base flaw (CWE) or working reproducer that reliably triggers it or some decent description of the flaw (do X/Y/Z and this weird thing happens that has a security impact)
Strongly required for CVE (not mandatory, but there better be a good reason for not having these):
-Affected component (e.g. function name, URL in web app, etc.)
-Link or example of vulnerable code or a link or example of the code fix
-What the security impact is (AIC?) if you can't explain what exploitation accomplishes we have a problem
Requested for CVE (it'll speed things up):
-CVSSv2/3 scoring information
On 2016-05-12 20:18, Kurt Seifried wrote:
> So for the DWF handling of Open Source vulnerabilities my plan is
> currently for the general case:
> Minimum required for CVE:
> -Software name (and/or URL if it's a common name used more than once)
> -Vulnerable version (one or more)
> -Base flaw (CWE) or working reproducer that reliably triggers it or some
> decent description of the flaw (do X/Y/Z and this weird thing happens
> that has a security impact)
I was thinking that decent description becomes the CVE name/title? Also
a title name should be required, even if there's also a good CWE match.
Something like "Vendor product (component) has a CWE-123." Encourage
good titles but accept anything reasonable.
Is the above enough for MITRE to import and create a CVE entry? I think
currently a somewhat trusted/authoritative public reference is also
> Strongly required for CVE (not mandatory, but there better be a good
> reason for not having these):
> -Affected component (e.g. function name, URL in web app, etc.)
> -Link or example of vulnerable code or a link or example of the code fix
> -What the security impact is (AIC?) if you can't explain what
> exploitation accomplishes we have a problem
> Requested for CVE (it'll speed things up):
> -Fixed version/commit
> -CVSSv2/3 scoring information
And all the above would be implemented in a DWF CSV row and collection
of artifacts? Require minimal JSON file?
On Thu, May 12, 2016 at 9:49 PM, Art Manion <[hidden email]> wrote:
On 2016-05-12 20:18, Kurt Seifried wrote:
So for example here's some recent CVE assignments from Red Hat (source info removed):
CVE-2016-3710 qemu: incorrect banked access bounds checking in vga module
CVE-2016-3711 haproxy: Setting cookie containing internal IP address of an OpenShift pod
CVE-2016-3714 ImageMagic MVG 1. Insufficient shell characters filtering leads to (potentially remote) code execution
CVE-2016-3715 ImageMagic MVG 3. File deletion
CVE-2016-3716 ImageMagic MVG 4. File moving
CVE-2016-3717 ImageMagic MVG 5. Local file read (independently reported by original research author - https://hackerone.com/stewie)
CVE-2016-3718 ImageMagic MVG 2. SSRF
this is roughly what I'm looking at (the ImageMagick ones for example are simply straight from the original email requesting the CVEs).
My goal will be to get the minimum for sure, the strongly recommended (essentially the only requests exempted will be the ones with a history of making perfect requests like OpenStack or Samba) and ideally start training people to add the requested (CVSS scoring data would make this data a lot more valuable, as evidenced by the fact NIST does this). In an ideal world with all that info an automated description would be trivial (a string with variables would do the basics no problem).
Correct, the JSON file will have 4 hierarchies of data within it:
-DWF (strongly regulated/formatted)
-Community (Guidelines provided, some regulation perhaps)
-Experimental (anything within reason goes)
-Vendor (strongly regulated, essentially sourcing information and vendor specific DWF type information, e.g. vendor-product-specific CVSS2 scoring perhaps)
|Free forum by Nabble||Edit this page|