This page last changed on Oct 13, 2008 by smaddox.

This page has information on how to report any security bugs you might find in Crowd, and what we will do to fix the problem and announce the solution.

On this page:

Finding and Reporting a Security Vulnerability

If you find a vulnerability in Crowd, please take the following steps to report it:

  1. Raise an issue on http://jira.atlassian.com:
    • Project — 'Crowd'
    • Issue Type — 'Bug'
    • Security Level — 'Reporters and Developers'
    • Priority — 'Blocker'
  2. Provide as much information as possible on how to reproduce the bug.

Please conduct all communication about the vulnerability through JIRA, so that we can keep track of the issue and get a patch out as soon as possible.

Publication of Security Advisories

When a security issue is discovered in Crowd, we will resolve it as quickly as possible. Once we have a solution, we will let our customers know as follows:

  • We will add a security advisory as a child of this page.
  • We will post a copy of the advisory on the Crowd Announcements forum. The forum posts are also sent to our mailing list. You can subscribe via the Atlassian website.

Severity Levels

Atlassian security advisories include a severity level, rating the vulnerability as one of the following:

  • Critical
  • High
  • Moderate
  • Low

Below is a summary of the factors which we use to decide on the severity level, and the implications for your installation.

Severity Level: Critical

We classify a vulnerability as critical if most or all of the following are true:

  • Exploitation of the vulnerability results in root-level compromise of servers or infrastructure devices.
  • The information required in order to exploit the vulnerability, such as example code, is widely available to attackers.
  • Exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials or knowledge about individual victims, and does not need to persuade a target user, for example via social engineering, into performing any special functions.
Severity Level: High

We give a high severity level to those vulnerabilities which have the potential to become critical, but have one or more mitigating factors that make exploitation less attractive to attackers.

For example, given a vulnerability which has many characteristics of the critical severity level, we would give it a level of high if any of the following are true:

  • The vulnerability is difficult to exploit.
  • Exploitation does not result in elevated privileges.
  • The pool of potential victims is very small.

Note: If the mitigating factor arises from a lack of technical details, the severity level would be elevated to critical if those details later became available. If your installation is mission-critical, you may want to treat this as a critical vulnerability.

Severity Level: Moderate

We give a moderate severity level to those vulnerabilities where the scales are slightly tipped in favour of the potential victim.

The following vulnerabilities are typically rated moderate:

  • Denial of service vulnerabilities, since they do not result in compromise of a target.
  • Exploits that require an attacker to reside on the same local network as the victim.
  • Vulnerabilities that affect only nonstandard configurations or obscure applications.
  • Vulnerabilities that require the attacker to manipulate individual victims via social engineering tactics.
  • Vulnerabilities where exploitation provides only very limited access.
Severity Level: Low

We give a low severity level to those vulnerabilities which by themselves have typically very little impact on an organisation's infrastructure.

Exploitation of such vulnerabilities usually requires local or physical system access. Exploitation may result in client-side privacy or denial of service issues and leakage of information about organisational structure, system configuration and versions, or network topology.

Original ranking compiled by the SANS Institute
Our vulnerability ranking is based on a scale originally published by the SANS Institute.

Patches and Fixes

When a security issue has been resolved, we will make the solution available as follows:

  • We will release a bug-fix version of Crowd as soon as possible.
  • Where feasible, we will issue a patch for the current stable version of Crowd and for older versions of Crowd. Patches will be attached to the relevant JIRA issue.

Published Security Advisories

Document generated by Confluence on Jul 30, 2009 01:29