Developer Area/Security Team
Here is a description of the rules and procedures that the security team follows.
- Above all else, we need to protect Mahara users to the best of our ability.
- We keep security vulnerabilities secret until a fix is released.
- Before fixes are released, we only share details of security flaws with people involved in releasing fixes.
- 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.
- 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.
- 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).
Here's roughly what we do when we receive notice of an unpublished security flaw:
- We review/test the report to confirm that it is a problem and create a private security bug on Launchpad.
- 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).
- We fix the problem on:
- the supported stable releases (i.e. the last two)
- the versions of the mahara package in Debian and Ubuntu
- The fixes are *now* reviewed through gerrit instead of being committed to the bug tracker.
- make security
- This is pushed to gerrit, and the "Mahara Security Managers" team is automatically subscribed
- The fixes are reviewed by another developer.
- Using gerrit for the security patches makes use of the "draft" feature.
- This means that you can't +1/-1 etc, but you can still give line comments and a general comment.
- Further patches are redone with `make security` again
- We request CVE numbers for each separate issue from firstname.lastname@example.org (see this email template)
- Mahara advisories (for the security forum) are prepared.
- We prepare, test and update Debian packages for oldstable and stable and submit them to the embargoed security queue.
- 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.
- 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.
- 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.
- 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:
- How can I fix this bug?
- Where else could the same problem pop up?
- 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:
- I can fix this bug by escaping the string.
- It could happen anywhere else in templates. So I need to check every Dwoo template.
- 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.