Re: Discussion of Well-Formed CVE Requests

[Kurt Seifried <kseifried@redhat.com>]

On Thu, May 12, 2016 at 9:49 PM, Art Manion <amanion@cert.org> wrote:

On 2016-05-12 20:18, Kurt Seifried wrote:

>     <http://cveproject.github.io/docs/requester/reservation-guidelines.html>____

> 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.

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). 

 

Is the above enough for MITRE to import and create a CVE entry?  I think
currently a somewhat trusted/authoritative public reference is also
required?

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). 

 

> 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?

 - Art

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)

 

 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com