Differences

This shows you the differences between two versions of the page.

--- mantisbt:handling_security_problems [2014/03/28 08:26] – dregad
+++ mantisbt:handling_security_problems [2017/03/10 04:39] – [Once the issue has been logged] reference @mentions dregad
@@ Line 2: / Line 2: @@
 This document provides guidelines to report security issues in MantisBT, and describes the process we follow to deal with them internally.
@@ Line 8: / Line 10: @@
 If you discover a security issue or what you think could be one, please
-[[http://www.mantisbt.org/bugs/bug_report_page.php?category_id=36&view_state=50|Open a new issue]] in our bug tracker following the guidelines below.
+[[http://www.mantisbt.org/bugs/bug_report_page.php?category_id=36&view_state=50|Open a new issue]]
+in our bug tracker following the guidelines below.
   * Set //Category// to **security** ((This field will be preset if you use the above link))
@@ Line 16: / Line 19: @@
   * Do not forget detailed //Steps To Reproduce// to facilitate our work in analyzing and fixing the problem
   * If you already have a patch for the issue, please attach it to the issue
-  * Should you wish to be credited for the finding, kindly indicate it under //Additional Information// or in a bug note. Your name/e-mail/company will be included in the CVE report
+  * CVE (([[http://cve.mitre.org/about/faqs.html|Common Vulnerabilities and Exposures ]])) handling
+    * To ensure a comprehensive and detailed declaration of the issue, we generally prefer [[#obtaining_a_cve_id|requesting CVEs]] ourselves
+    * The request is usually sent after analysis and development of a patch (to avoid early disclosure)
+    * Should you wish to be credited for the finding, kindly indicate it under //Additional Information// or in a bug note. \\ Your name/e-mail/company will be included in the CVE report as specified.
+    * In case you have already obtained a CVE, do not forget to reference its ID in the bug report
 One of the core team members will review, reply, ask for additional information as required.
-We will then discuss the means of fixing the vulnerability and agree on a calendar for disclosure. Generally this discussion takes place within the issue itself, but in some cases it may happen privately.
+We will then discuss the means of fixing the vulnerability and agree on a calendar for disclosure. Generally this discussion takes place within the issue itself, but in some cases it may happen privately, e.g. by e-mail.
 Note: **do not** submit a Github Pull Request or post on the mailing list, as these are public channels which would effectively disclose the security issue.
@@ Line 31: / Line 39: @@
 If you are notified of a security issue directly (e.g. by e-mail), start by logging the issue in the tracker as described in the [[#for_users|section above]].
-Once the issue has been logged:
-  - If you were not the issue's reporter, take ownership of it (i.e. Assign to yourself)
-  - Notify the rest of the core team about the vulnerability by adding them to the email thread / issue discussion (use the //Send Reminder// feature)
-  - Propose a fix by **attaching a git patch** to the issue ((It is important to not leak information about the vulnerability by pushing fixes to the public repositories before the disclosure.)).
-  - The original reporter as well as at least one other MantisBT developer should review and test the fix, and provide feedback
-Once the fix has been tested and confirmed to resolve the issue:
+==== Once the issue has been logged ====
+  - Take ownership of the issue
+    * Assign it to yourself
+    * Update //Priority// and //Severity// as appropriate
+    * Set //Target Version// to the next stable release (e.g. "1.2.x")
+    * Make sure it is indeed **Private**
+  - Notify the rest of the core team about the vulnerability by adding them to the email thread / issue discussion((Do not use the Developer's mailing list to avoid early disclosure.)) (use //@mentions// or the //Send Reminder// feature)
+  - Propose a fix by **attaching a git patch** to the issue ((It is important not to leak information about the vulnerability by pushing fixes to the public Github repositories before the disclosure.))
+  - The original reporter should test the fix to confirm resolution
+  - If possible, at least one other MantisBT developer should review and test the fix as well
+==== Once the fix has been tested ====
+Feedback from the Reporter and a peer review confirm that the fix addresses the issue.
   - Agree with the reporter to a timeline for disclosure
   - Commit the fix to both the stable and development branches, and push to Github.
-  - Obtain a [[#obtaining_a_cve_id|CVE ID]](([[http://cve.mitre.org/about/faqs.html|Common Vulnerabilities and Exposures ]])) for the issue ((The OSS-Security mailing list is public, so requesting a CVE ID de facto discloses the vulnerability))
+  - [[#obtaining_a_cve_id|Obtain a CVE ID]](([[http://cve.mitre.org/about/faqs.html|Common Vulnerabilities and Exposures ]])) for the issue ((The oss-security mailing list is public, so requesting a CVE ID de facto discloses the vulnerability)) as explained in the next section
+  - Once a CVE ID has been assigned, the bugtracker issue summary must be updated
+    * Prefix the //Summary// with the CVE ID (see [[mantis>16513]] for example)
+    * Make the issue **Public**
+    * Set //Fixed in version//
+    * Mark it as **Resolved** / **Fixed**
   - As soon as possible after disclosure, [[release_process|prepare a new security release]] for the affected MantisBT branches
@@ Line 49: / Line 75: @@
 ==== Obtaining a CVE ID ====
-First of all, send an e-mail to the [[http://oss-security.openwall.org/wiki/mailing-lists/oss-security|oss-security mailing list]] (does not require subscription) as per the following examples [[http://thread.gmane.org/gmane.comp.security.oss.general/11351|1]], [[http://thread.gmane.org/gmane.comp.security.oss.general/9876|2]]. The request must include:
+Refer to Kurt Seifried's [[https://github.com/RedHatProductSecurity/CVE-HOWTO#how-do-i-request-a-cve|CVE HowTo]] for the process to request a CVE ID.
+The request must include:
   - description of the issue, including but not limited to
@@ Line 62: / Line 90: @@
   - optionally, attach the patch itself
-Once a CVE ID has been assigned, the bugtracker issue summary must be updated (i.e prefixed) with it , see ~~Mantis:16513~~ for example.
+Here are a few **examples** of public CVE requests:
+[[http://thread.gmane.org/gmane.comp.security.oss.general/15434|1]],
+[[http://thread.gmane.org/gmane.comp.security.oss.general/15429|2]],
+[[http://thread.gmane.org/gmane.comp.security.oss.general/11351|3]],
+[[http://thread.gmane.org/gmane.comp.security.oss.general/9876|4]].
+From experience, the CVE ID usually gets assigned within one business day, but sometimes it takes up to a week.