XWiki Security Policy

Version 16.1 by Simon Urli on 2023/05/16 10:22

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.

What are the available channels to discuss about security issues?

Four channels are available with different usages.

Security Forum & Mailing-List

The main discussion channel is the private security forum category . However, this channel is private and for this reason, we've kept the old mailing-list (security[at]xwiki.org) since anyone can post on it (but only core committers and some other trusted persons can read them). See also Mailing Lists.

The forum channel must be used for warning 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 level set to Confidential and the security label. Those issues are only visible to people who submitted them, to the committers of XWiki, and to anyone trusted by the XWiki committers who can help fixing them. 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. Note that the label “security” could be used in JIRA dashboard or in Release Notes to inform about the fixed security issues.

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.
More information are available on Chat.

Github Security Advisories

For each security issue fixed for XWiki, a dedicated security advisory is created on Github. Those advisories remain private until they are publicly disclosed. By default, the owners of a Github organization can view the advisories: in the case of XWiki, the Github organization is owned by all XWiki committers.
On top of that, access to the advisories is also manually granted to a dedicated Github Team for trusted people who are not committers, to see the advisories before they are publicly disclosed.

People wanting to get access to this Github Team should request access on the security mailing-list.

Where to submit security issues?

As specified above, all security issues should be submitted on https://jira.xwiki.org with the level set to Confidential and the security label. Try to give as much information as possible for those issues and in particular a way to exploit the vulnerability, or a way to assess that the vulnerability is present: we will use it to determine if some instances are subject to it or not.

Those issues are only visible to people who submitted them, to the committers of XWiki and to anyone trusted by the XWiki committers who could help fixing them.

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

When adding a new label in JIRA for attackers or attacks, you need to also edit the following 2 filters to add the new labels:

Types of attackers

LabelDescription
attacker_guestThe attacker doesn’t need to be logged-in to perform the attack.
attacker_accountThe attacker needs to be logged-in to perform the attack.
attacker_viewThe attacker needs to have view right to perform the attack.
attacker_commentThe attacker needs to be logged-in and the comment rights to perform the attack.
attacker_editSame as above but with edit rights.
attacker_scriptSame as above but with script rights.
attacker_socialengThe attacker can only perform the attack if he has physical access to the target device

Types of attacks

LabelDescription
attack_stabilityAttacks that are related to targeting the host (e.g. DOS attack)
attack_escalationAttacks that are related to permanently getting more rights
attack_loginAttacks that are related to login with another user identity
attack_xssAll attacks related to code injection
attack_impersonationAttacks that are related to using another people right to perform actions
attack_dataleakAttacks 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.
attack_spamAttacks that are related to spamming

Severity

The severity of the security tickets should be computed using a CVSS calculator such as https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator.

Note that we only use the base metrics right now for computing CVSS in XWiki.

A proposed severity mapping for our JIRA tickets using the CVSS score is the following:

  • 0.1 - 3.9: Minor
  • 4.0 - 6.9: Major
  • 7.0 - 8.9: Critical
  • 9.0 - 10.0: Blocker

Best practices for computing CVSS

In general it's good to refer to the official documentation for understanding CVSS, and to also look on the examples to better understand the different criteria.
Besides this, some best practices have been established for computing CVSS specifically for XWiki tickets.

Attack vector

It should always be Network.

Attack complexity

We don't have a specific best practice for this yet: the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.

Privileges Required

We defined the following mapping to apply the privileges required from CVSS which is a very discretized scope, to the continuum of rights from XWiki:

  • None: Apply for any vulnerability that might be done with Guest user with standard XWiki right, AND with Guest user with Comment right as it’s a supported UC in XWiki which is supposed to prevent giving more rights to Guest
  • Low: Apply for any vulnerability that might be done with registered users with standard XWiki right (note that it includes Script right for XWiki < 14.10)
  • High: Apply for any vulnerability that involves more right than the standard XWiki right (can be allowing Script right for XWiki 14.10+, or Delete on the whole wiki, admin on a space etc)

Note that when we refer to standard XWiki right above we mean bundled rights scheme in Xwiki Standard.

User Interaction

We don't have a specific best practice for this yet: the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.

Scope

We don't have a specific best practice for this yet: the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.

Confidentiality Impact

 

In case of XSS vulnerability the impact should always be set to High.

For other cases the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.

Integrity Impact

In case of XSS vulnerability the impact should always be set to High.

For other cases the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.

Availability Impact

In case of XSS vulnerability the impact should always be set to High.

For other cases the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.

Deprecated Severity Matrix

  The following severity matrix was used for computing the severity of our security tickets, before we started to enforce the usage of CVSS. It's now only provided as an indicative tool to read our old JIRA tickets.

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 \ Attackersguestaccount or viewcommenteditscriptsocialeng
stabilityHighHighHighMediumMediumLow
escalationHighHighHighHighMediumLow
impersonationHighHighHighHighMediumLow
loginHighHighHighMediumLowLow
xssHighHighHighMediumLowLow
dataleakHighHighHighMediumLowLow
spamHighHighHighMediumLowLow

Note: in 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 the following mapping:

  • High severity: Blocker in JIRA
  • Medium severity: Critical in JIRA
  • Low severity: Major in JIRA

Blocker issues have to be fixed before the next release. There’s no obligations about critical and major issues, so they are handled depending on the other priorities of the core committers.

On the 2022-07-07 the use of the JIRA "Development Priority" field was stopped and only the "Priority" one is used from then on.

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 and the fix has been released, a CVE is published to publicly disclose about this issue and to incitate for an upgrade. The CVE is mandatory for any security issues.

How long does it take to publish a CVE?

Once an issue has been fixed and released, an embargo of at least 3 months is starting to allow anyone working with XWiki to perform actions before the publication of the CVE. The embargo might be longer than 3 months, in which case extending the embargo might be decided through a vote on the forum. 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?

  1. Take the ownership on the security issue by assigning the JIRA ticket to yourself.
  2. Validate the information about the security issue
    • Verify that the Confidential level is set
    • Verify that the security labels are set and are correct
    • Verify that the security label is set (needed for example to know which issues are security issues when the Confidential level is removed)
    • Provide missing information, and, in particular, make sure that the issue contains reproduction steps to either exploit the vulnerability or assess its presence
  3. Announce the problem on the security section of the forum
  4. Fix the issue on all supported branches
  5. Create a draft advisory on Github (see section below).
  6. Add a link to the advisory draft on the JIRA issue(s)
  7. Announce the fix on the security section of the forum with the list of branches where the fix is provided and the link to the advisory
  8. When all XWiki versions where the fix is provided are released, announce on the security list that the 3 months embargo is starting and specify the date when the issue will be made public
  9. After 3 months, request a CVE through GitHub Advisory page. Remove the Confidential level on the Jira issue. Publish the advisory once the CVE ID has been received.

Security Advisory template and information

For global information of creating a Github advisory, you can consult the official documentation: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/creating-a-repository-security-advisory.

You can find below a template to use for the content of a new security advisory:

### Impact

Describe here the impact of the vulnerability and provide information about the versions of XWiki impacted by it.

### Patches

Provide in the section the list of patched versions of XWiki. You can also provide some details about the patches.

### Workarounds

Provide information how to workaround the vulnerability when it's possible. If not possible, inform that users should upgrade to get the fix.

### References

You should list here the JIRA ticket(s) related to this vulnerability and when possible the commit that patches it, especially if that's a single one.
Don't hesitate to provide more pointers when they make sense.

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)
* Email us at [Security Mailing List](mailto:[email protected])

### Attribution

You can specify here who reported the issue.

The versions set in the security advisory should follow the best practices documented in https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/best-practices-for-writing-repository-security-advisories#affected-versions. Then don't forget to pay attention to the format of the version (e.g. 14.10RC1 is not a right version: you should use 14.10-rc-1).

The severity of the vulnerability should be assessed using CVSS, you can find information and a calculator here to help you: https://www.first.org/cvss/v3-1/. You should also try to find a CWE corresponding to the vulnerability. You can browse and search for the closest one using the official website: https://cwe.mitre.org/data/index.html.

Finally you should not forget to add "XWiki/Security" Github Team as collaborator of your advisory to ensure proper people are able to see it.

 

Tags:
   

Get Connected