Discussion of Well-Formed CVE Requests

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Discussion of Well-Formed CVE Requests

Common Vulnerabilities & Exposures

Greetings,

 

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:

 

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

 

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

 

Reply | Threaded
Open this post in threaded view
|

Re: Discussion of Well-Formed CVE Requests

Kurt Seifried


On Tue, May 10, 2016 at 9:41 AM, Common Vulnerabilities & Exposures <[hidden email]> wrote:

Greetings,

 

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:

 

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

 

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

 


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):
-Fixed version/commit
-CVSSv2/3 scoring information






--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Discussion of Well-Formed CVE Requests

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

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?

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Discussion of Well-Formed CVE Requests

Kurt Seifried


On Thu, May 12, 2016 at 9:49 PM, Art Manion <[hidden email]> 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: [hidden email]