Developer Area/Security Team
From Mahara Wiki
< Developer AreaRevision as of 17:39, 7 October 2011 by Francois (how to fix security bugs properly)
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 not reviewed through gerrit or committed to the bug tracker. Instead, they are attached as patches to the private bugs on Launchpad.
- The fixes are reviewed by another developer manually.
- We request CVE numbers for each separate issue from [email protected]
- 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 submitted through gerrit (marked as "verified +1" "code review +2" by the submitter) and ends with official announcements.
- The Debian unstable package is uploaded and debdiffs for Ubuntu packages are posted on Launchpad.
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.