User Tools

Site Tools


mantisbt:handling_security_problems

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
mantisbt:handling_security_problems [2014/03/28 08:24]
dregad
mantisbt:handling_security_problems [2017/03/10 07:26]
dregad [Obtaining a CVE ID] New process to request CVE via MITRE's form
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. 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  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))   * 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   * 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   * 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.  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. 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 30: 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]]. 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 (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   - Agree with the reporter to a timeline for disclosure
   - Commit the fix to both the stable and development branches, and push to Github.   - 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   - As soon as possible after disclosure, [[release_process|prepare a new security release]] for the affected MantisBT branches
 +
  
  
Line 48: Line 75:
 ==== Obtaining a CVE ID ==== ==== 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:+Fill the form at https://cveform.mitre.org/, following indications on the page. 
 + 
 +  * //Vendor of the product// and //Product// should be set to **MantisBT** 
 +  * a couple of examples for the //Version// field:  
 +    - Single version: 2.1.0 and later; fixed in 2.2.
 +    - Multiple versions: 1.3.0-beta.3 through 2.2.0, fixed in 1.3.72.2.1 
 +  * //Affected components//the MantisBT page(s) where the problem exists 
 +  * //References// should include (if public) links to 
 +    - the MantisBT issue  
 +    - Github commit(s) with patches fixing the issue 
 + 
 +Once the form has been submitted, the system will send a confirmation e-mail with a request number; after review, MITRE's CVE assignment team will send another e-mail with the CVE IDFrom experience, the CVE ID usually gets assigned within one business day. 
 + 
 +Note that There are alternatives to request CVE IDs; refer to Kurt Seifried's [[https://github.com/RedHatProductSecurity/CVE-HOWTO#how-do-i-request-a-cve|CVE HowTo]] for further information.
  
-  - description of the issueincluding but not limited to +Here are a few **examples** of public CVE requestsrequested via the //oss-security Mailing List//:  
-     * type, e.gXSS, sql injection... +[[http://thread.gmane.org/gmane.comp.security.oss.general/15434|1]],  
-     * which area of Mantis are affected +[[http://thread.gmane.org/gmane.comp.security.oss.general/15429|2]],  
-     * potential consequences of exploiting the bug +[[http://thread.gmane.org/gmane.comp.security.oss.general/11351|3]] 
-     * indication on severity +[[http://thread.gmane.org/gmane.comp.security.oss.general/9876|4]]. 
-  - affected MantisBT version(s) +
-  - link to MantisBT issue +
-  - optionallyinformation about the reporter (if available and they do not refuse to be quoted) +
-  - information about the patch (i.ewhere it can be foundcommit SHA) +
-  - optionallyattach 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. 
  
mantisbt/handling_security_problems.txt · Last modified: 2017/03/10 07:34 by dregad