Hi everyone,
we just published our first security advisory on Github, so I’d like to submit to vote a general process for handling security issue. If everyone agrees on it, then it will become the rules for handling them for committers and I’ll publish it on xwiki.org. Note that this is pretty important since it might also impact the sponsored companies of XWiki. Also consider that we comply to those rules for the security advisory we just published in order to prove it’s working (at least for one occurence).
The vote is open for two weeks until May 26th.
Here’s my +1.
Below the document to vote to.
Thanks.
XWiki Security Policy
The goal of this document is to provide some information about the policy of XWiki.org in case a vulnerability is found in XWiki Standard.
It aims at being published on https://github.com/xwiki/xwiki-platform/security/policy and to be referenced wherever it’s needed (in particular on https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Security and https://dev.xwiki.org/xwiki/bin/view/Community/Security)
What are the available channels to discuss about security issues?
Three channels are available with different usages.
Security Mailing-List
The main channel is the security mailing-list (security[at]xwiki.org). Anyone can post on this mailing-list, but only core committers and some key people from sponsoring companies received those emails.
This channel must be used for preventing the sponsoring companies that a new security issue has been discovered. It might be used for asking about a potential security issue.
JIRA
The JIRA of XWiki (https://jira.xwiki.org) is the right place to submit issues by using the visibility set to Confidential. Those issues are only visible to people who submitted them and to the committers of XWiki. All informations about the submitted issues if discussed elsewhere should be added on the comments of the issues so that the reporter can follow them.
Matrix
A dedicated Matrix Chat room is dedicated to talk about security issues but is dedicated to the same people as the security mailing-list. It should be mainly used to discuss about the security policy and technical details about a specific issue.
Where to submit security issues?
As specified above, all security issues should be submitted on https://jira.xwiki.org with the visibility set to Confidential.
Those issues are only visible to people who submitted them and to the committers of XWiki.
What are the criteria for computing severity?
The severity is defined case by case by the core committers depending on two criteria:
- the impact of the security issue (e.g. an issue that might impact all pages of a wiki is more severe than an issue which might impact only pages with specific rights)
- and the difficulty to reproduce it (e.g. an issue which needs script rights to be reproduced is less severe than an issue which only needs view access on the wiki)
We currently use two types of labels to compute the severity of an issue: the type of attacker (depending on its rights on the wiki) and the type of attack (depending on what he can actually do).
Types of attackers
| Label | Description |
|---|---|
| attacker_guest | The attacker doesn’t need to be logged-in to perform the attack. |
| attacker_view | The attacker needs to be logged-in to perform the attack. |
| attacker_comment | The attacker needs to be logged-in and the comment rights to perform the attack. |
| attacker_edit | Same as above but with edit rights. |
| attacker_script | Same as above but with script rights. |
| socialeng | The attacker can only perform the attack if he has physical access to the target device |
Types of attacks
| Label | Description |
|---|---|
| stability | Attacks that are related to targeting the host (e.g. DOS attack) |
| escalation | Attacks that are related to permanently getting more rights |
| login | Attacks that are related to login with another user identity |
| xss | All attacks related to code injection |
| impersonation | Attacks that are related to using another people right to perform actions |
| dataleak | Attacks that are related to confidential data that might be retrieved in readonly: could be emails, but could also be XWiki document that shouldn’t be viewable. |
| spam | Attacks that are related to spamming |
Severity matrix
DISCLAIMER: This severity matrix is only indicative, the severity is computed on a case-by-case basis only.
How to read this matrix:
- columns are representing the type of attackers
- lines are representing the type of attacks
- values are a severity between high / medium / low
| Attacks \ Attackers | guest | view | comment | edit | script | socialeng |
|---|---|---|---|---|---|---|
| stability | High | High | High | Medium | Medium | Low |
| escalation | High | High | High | High | Medium | Low |
| impersonation | High | High | High | High | Medium | Low |
| login | High | High | High | Medium | Low | Low |
| xss | High | High | High | Medium | Low | Low |
| dataleak | High | High | High | Medium | Low | Low |
| spam | High | High | High | Medium | Low | Low |
Note: on the future we’ll need to formalize the usage of https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator to compute the severity of our security.
How long does it take to fix a security issue?
The priority of the JIRA issue is set depending on the severity of the issue, we apply basically the following mapping:
- high severity: blocker
- medium severity: critical
- low severity: major
Blocker issues have to be fixed before next release. There’s no obligations about critical and major issues, so they are handled depending on the other priorities of the core committers.
When is a security issue considered as fixed?
Security issues are considered as fixed only once the fix is part of releases for all supported branches impacted by the issue. So for example, if XWiki.org is currently in the 12.x cycle and a security issue impacts both 11.10.1 (LTS) and 12.3 (stable), the issue is fixed when 11.10.2 and 12.3.1 (or 12.4) are released with the fix.
Are security issues ever publicly disclosed?
Once the issue has been properly fixed, a CVE might be published to publicly disclose about this issue and to incitate for an upgrade. The CVE is not mandatory and should happen only in case of issues with a high severity.
If no CVE is published, the issue and its details are never publicly disclosed, but the release notes will mention that some security issues have been fixed.
How long does it take to publish a CVE?
Once an issue has been fixed and released, an embargo of 3 months is starting to allow anyone working with XWiki to perform actions before the publication of the CVE. The sponsoring companies are automatically informed as soon as a security issues has been discovered through the security communication channels.
For example, if a security issue has been fixed and released in 11.10.2 and in 12.0, respectively released the 5th of February and the 29th of January, the CVE could be published 3 months after latest release: i.e. the 5th of May.
What’s the process to handle security issues for committers?
- Once the issue has been validated by a developer taking the ownersnip of fixin the issue, create an draft advisory on Github (see: https://help.github.com/en/github/managing-security-vulnerabilities/creating-a-security-advisory). As part of this compute the security score (severity)
- Add a comment to the jira issue with a link to the advisory
- If the severity of the issue is high, announce the problem to all supporting companies by using the dedicated security communication channel
- Fix the issue on all supported branches and release XWiki. For low level security issues add them to the RN
- Annnounce the fix on the security list with the start of the 3 months timer clock. Make it part of the Release Plan for the RM to do.
- After 3 months, request a CVE (for high criticity issues only FTM) through GitHub Advisory page. Remove the confidential label on the Jira issue. Publish the advisory once the CVE ID has been received.