User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

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 revisionPrevious revision
Next revision
Previous revision
mantisbt:handling_security_problems [2014/10/30 08:04] – Detail CVE handling dregadmantisbt:handling_security_problems [2021/07/14 12:08] (current) – Must be logged in with mantisbt.org account 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. This document provides guidelines to report security issues in MantisBT, and describes the process we follow to deal with them internally.
 +
  
  
Line 9: 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]] +[[https://mantisbt.org/bugs/bug_report_page.php?category_id=36&view_state=50|Open a new issue]] 
 +((You must be logged-in with your mantisbt.org account to use this link))  
 in our bug tracker following the guidelines below. in our bug tracker following the guidelines below.
  
Line 18: Line 20:
   * 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
-  * CVE handling+  * 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     * 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)     * The request is usually sent after analysis and development of a patch (to avoid early disclosure)
Line 47: Line 49:
     * Set //Target Version// to the next stable release (e.g. "1.2.x")     * Set //Target Version// to the next stable release (e.g. "1.2.x")
     * Make sure it is indeed **Private**     * 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 the //Send Reminder// feature)+  - 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.))   - 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 as well should test the fix to confirm resolution+  - 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   - If possible, at least one other MantisBT developer should review and test the fix as well
  
Line 63: Line 65:
   - [[#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   - [[#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   - 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)+    * Prefix the //Summary// with the CVE ID (see [[mantis>16513]] for example)
     * Make the issue **Public**     * Make the issue **Public**
     * Set //Fixed in version//     * Set //Fixed in version//
     * Mark it as **Resolved** / **Fixed**     * 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 73: Line 76:
 ==== Obtaining a CVE ID ==== ==== Obtaining a CVE ID ====
  
-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]]. +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.1 
 +    - Multiple versions: 1.3.0-beta.3 through 2.2.0, fixed in 1.3.7, 2.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 ID. From experience, the CVE ID usually gets assigned within one business day. 
 + 
 +Note that There are alternatives to request CVE IDs; refer to Kurt Seifried'[[https://github.com/RedHatProductSecurity/CVE-HOWTO#how-do-i-request-a-cve|CVE HowTo]] for further information. 
 + 
 +Here are a few **examples** of public CVE requests, requested via the //oss-security Mailing List//:  
 +[[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]]. 
  
-The request must include:+==== Reference the CVE ID ====
  
-  - description of the issueincluding but not limited to +Once the CVE ID has been assignedit must be referenced in MantisBT, and used in every communication related to the security issue
-     * type, e.g. XSS, sql injection... +
-     * which area of Mantis are affected +
-     * potential consequences of exploiting the bug +
-     * indication on severity +
-  - 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.e. where it can be found, commit SHA) +
-  - optionally, attach the patch itself+
  
-Usually, the CVE ID gets assigned within one business day.+  * MantisBT's issue tracker (**Mandatory**): prefix the issue's summary with ''CVE-YYYY-XXXX - '' 
 +  * in commit messages 
 +  * on GitHub pull requests 
 +  * in mailing lists discussions 
 +  * in announcements (e.g. release notes, blog post, twitter...
 +  * etc
  
mantisbt/handling_security_problems.1414670673.txt.gz · Last modified: 2014/10/30 08:07 (external edit)

Driven by DokuWiki