Table of Contents

Handling Security Issues

This document provides guidelines to report security issues in MantisBT, and describes the process we follow to deal with them internally.

For users

If you discover a security issue or what you think could be one, please Open a new issue 1) in our bug tracker following the guidelines below.

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, 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.

For developers

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 section above.

Once the issue has been logged

  1. 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
  2. Notify the rest of the core team about the vulnerability by adding them to the email thread / issue discussion5) (use @mentions or the Send Reminder feature)
  3. Propose a fix by attaching a git patch to the issue 6)
  4. The original reporter should test the fix to confirm resolution
  5. 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.

  1. Agree with the reporter to a timeline for disclosure
  2. Commit the fix to both the stable and development branches, and push to Github.
  3. Obtain a CVE ID7) for the issue 8) as explained in the next section
  4. Once a CVE ID has been assigned, the bugtracker issue summary must be updated
    • Prefix the Summary with the CVE ID (see 16513 for example)
    • Make the issue Public
    • Set Fixed in version
    • Mark it as Resolved / Fixed
  5. As soon as possible after disclosure, prepare a new security release for the affected MantisBT branches

Obtaining a CVE ID

Fill the form at https://cveform.mitre.org/, following indications on the page.

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's CVE HowTo for further information.

Here are a few examples of public CVE requests, requested via the oss-security Mailing List: 1, 2, 3, 4.

Reference the CVE ID

Once the CVE ID has been assigned, it must be referenced in MantisBT, and used in every communication related to the security issue.

1)
You must be logged-in with your mantisbt.org account to use this link
2) , 3)
This field will be preset if you use the above link
5)
Do not use the Developer's mailing list to avoid early disclosure.
6)
It is important not to leak information about the vulnerability by pushing fixes to the public Github repositories before the disclosure.
8)
The oss-security mailing list is public, so requesting a CVE ID de facto discloses the vulnerability