mantisbt:handling_security_problems
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
mantisbt:handling_security_problems [2014/03/28 08:31] – Add subtitles dregad | mantisbt:handling_security_problems [2017/03/10 07:34] – Add "Reference the CVE" section 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 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:// | + | [[http:// |
+ | in our bug tracker following the guidelines below. | ||
* Set // | * Set // | ||
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 // | + | |
+ | * To ensure a comprehensive and detailed declaration of the issue, we generally prefer [[# | ||
+ | * The request is usually sent after analysis and development of a patch (to avoid early disclosure) | ||
+ | | ||
+ | * 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 31: | Line 38: | ||
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 [[# | 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 [[# | ||
+ | |||
+ | |||
==== Once the issue has been logged ==== | ==== Once the issue has been logged ==== | ||
- | - If you were not the issue' | + | - Take ownership of the issue |
- | - Notify the rest of the core team about the vulnerability by adding them to the email thread / issue discussion (use the //Send Reminder// feature) | + | * Assign |
- | - Propose a fix by **attaching a git patch** to the issue ((It is important | + | * Update // |
- | - The original reporter | + | * Set //Target Version// to the next stable release |
+ | * 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' | ||
+ | - 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 | ||
+ | - 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 47: | Line 62: | ||
- 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 [[# | + | - [[# |
+ | - Once a CVE ID has been assigned, the bugtracker issue summary must be updated | ||
+ | * Prefix the //Summary// with the CVE ID (see [[mantis> | ||
+ | * 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 | ||
+ | |||
+ | |||
==== Obtaining a CVE ID ==== | ==== Obtaining a CVE ID ==== | ||
- | First of all, send an e-mail | + | Fill the form at https:// |
+ | |||
+ | * // | ||
+ | * 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 issue | ||
+ | - Github commit(s) with patches fixing the issue | ||
+ | |||
+ | Once the form has been submitted, the system will send a confirmation | ||
+ | |||
+ | Note that There are alternatives to request CVE IDs; refer to Kurt Seifried' | ||
+ | |||
+ | Here are a few **examples** of public CVE requests, requested via the // | ||
+ | [[http:// | ||
+ | [[http:// | ||
+ | [[http:// | ||
+ | [[http:// | ||
+ | |||
+ | ==== Reference the CVE ID ==== | ||
- | - description of the issue, including but not limited to | + | Once the CVE ID has been assigned, it must be referenced in MantisBT, and used in every communication related |
- | * type, e.g. XSS, sql injection... | + | |
- | * which area of Mantis are affected | + | |
- | * potential consequences of exploiting the bug | + | |
- | * indication on severity | + | |
- | - affected | + | |
- | - link to MantisBT issue | + | |
- | - optionally, information about the reporter (if available | + | |
- | - information about the patch (i.e. where it can be found, commit SHA) | + | |
- | - optionally, attach the patch itself | + | |
- | Once a CVE ID has been assigned, | + | * MantisBT' |
+ | * in commit messages | ||
+ | * on GitHub pull requests | ||
+ | * in mailing lists discussions | ||
+ | * in announcements | ||
+ | * etc | ||
mantisbt/handling_security_problems.txt · Last modified: 2021/07/14 12:08 by dregad