Developer Area/Security Team

Here is a description of the rules and procedures that the security team follows.

Guiding principles

1. Above all else, we need to protect Mahara users to the best of our ability.
2. We keep security vulnerabilities secret until a fix is released.
3. Before fixes are released, we only share details of security flaws with people involved in releasing fixes.
4. Once fixes are public, we release details of the flaws (i.e. full disclosure) but we do not provide exploit code which makes it easy to exploit unpatched sites.
5. We release security fixes as soon as possible, balancing the urgency/severity of a problem as well as the frequency of updates for site admins. Therefore we may "sit" on non-critical and non-public issues for a short time in order to include them as part of a larger security update.
6. If the details of a security issue are made public before a fix is released, we can unhide the relevant bugs but we must release a fix as soon as possible (i.e. we cannot sit on those ones).

Procedures

Here's roughly what we do when we receive notice of an unpublished security flaw:

1. We review/test the report to confirm that it is a problem and create a private security bug on Launchpad.
2. We acknowledge receipt of the problem to the reporter and ask them to keep it quiet while we release a fix for it (we also ask how they want to be credited with the discovery of this problem).
3. We fix the problem on:
   1. the supported stable releases (i.e. the last two)
   2. the versions of the mahara package in Debian and Ubuntu
   3. master
4. The fixes are *now* reviewed through gerrit instead of being committed to the bug tracker.
   1. make security
   2. This is pushed to gerrit, and the "Mahara Security Managers" team is automatically subscribed
5. The fixes are reviewed by another developer.
   1. Using gerrit for the security patches makes use of the "draft" feature.
   2. This means that you can't +1/-1 etc, but you can still give line comments and a general comment.
   3. Further patches are redone with `make security` again
6. We request CVE numbers for each separate issue from [email protected] (see this email template)
7. Mahara advisories (for the security forum) are prepared.
8. We prepare, test and update Debian packages for oldstable and stable and submit them to the embargoed security queue.
9. Once everything is ready, we run through the release process. This starts with the fixes being published and submitted through gerrit (marked as "verified +1" "code review +2" by the submitter) and ends with official announcements.
   1. To submit it through gerrit fully, take the draft change (from above), and the "OWNER" needs to click publish and then a reviewer can "verified +1" and "code review +2" and submit.
   2. The limitation of the owner needing to do this is in the works of being fixed. There is a fix upstream in gerrit, but not in stable.
10. The Debian unstable package is uploaded and debdiffs for Ubuntu packages are posted on Launchpad.

Fixing security bugs the right way

When preparing a fix for a security bug, we need to ask three questions:

1. How can I fix this bug?
2. Where else could the same problem pop up?
3. What could we do in Mahara to prevent bugs like this one to ever happen again?

Here's an example of the thought process for a cross-site scripting bug that someone reported:

1. I can fix this bug by escaping the string.
2. It could happen anywhere else in templates. So I need to check every Dwoo template.
3. We could prevent this from happening by turning template auto-escaping ON.

In other words, we are fixing the problem in two ways and we are making sure that we fix all instances of this problem at once.