Ubuntu Wiki

Introduction

Marking an Ubuntu bug as a "security bug" (handled by the Ubuntu Security Team) means that the bug affects the security of the system in some way, resulting in a loss or degradation of security measures. Various categories might include:

• gaining privileges of another user without authorization. For example, a stack overflow in a setuid program allowing a regular user to become the root user. ("Privilege Escalation")
• accessing information that should be blocked. For example, a user on the system being able to view or modify private files of another user. ("Loss of Privacy")
• causing data-loss for another user. For example, a flaw in a database application allows a user to corrupt another user's stored information. ("Data Corruption")
• regression in security features. For example, if the default password hashing algorithm reverts to DES from md5. ("Regression")
• causing system services to become unavailable. For example, a network daemon can be taken offline remotely. ("Remote Denial of Service")

Marking an Ubuntu security bug as "private" is done in situations where a vulnerability is not yet publicly known. Attempts should be made to contact the upstream project (and other Linux Distributions) privately so that a "coordinated release date" (CRD) can be established. During this time, upstreams and Distributions can work to solve the problem before it goes public, in the hopes of heading off any public exploitation of the flaw. In situations where an upstream and Distributions are not interested in a CRD, the bug can made public so more developers can view the issue. (See "How to Forward" below for more details.)

All security flaws are assigned a CVE identifier. This is used to globally track the flaw so that other Distributions have a common identifier that can be used to discuss the flaw and its solution.

How to File

New security bugs should be created in the Ubuntu bug tracker (Launchpad). If you do not have a Launchpad account and prefer not to create one, you may send your report to security@ubuntu.com. We also accept GPG-encrypted mail.

To report a security vulnerability in an Ubuntu package, follow the regular bug-filing instructions, but take special note of the "Mark as security issue" check box near the bottom of the form:

By default, all security bugs start their life marked as "private". If the security issue is already public (e.g. in another public bug tracker, discussed on a public mailing list, etc), please follow the "publicly disclose" link in the messages above the filed report:

In the privacy/security page, you can uncheck the "private" flag, and save the bug:

As with all bugs, please include as much information as possible, including the steps to reproduce the issue starting from a stock installation. In some more complex situations, it can help to carefully explain the difference between the expected results and the unexpected results. (There are many applications in Ubuntu, and most developers do not have familiarity with all of them.)

Subscriptions, Assignments, and Tags

Security bugs automatically have the "ubuntu-security" team subscribed. If the report is against a package in the "universe" repository, it can help with triage to subscribe the "motu-swat" team. This is especially true for private bugs, where there is already a very small audience available to triage bugs.

Please do not assign any team to a bug -- this is only done for MIR Audit requests. Subscriptions are sufficent to get the attention of needed teams.

Tags are used to help track specific classes of bugs or wishlist items. Please use the following tags to identify certain situations:

• "hardened-ftbfs" When a package does not build due to the hardened CompilerFlags, and a solution is not immediately known, please add this tag.

• "format-security" When a package's build log shows *printf format security warnings ("warning: format is not string literal"), and needs attention to fix possible issues.
• "missing-nx" When a package is built where a program's stack is needlessly marked executable. This tends to happen when there is direct assembly being compiled in and it lacks the stack non-execute bits.

If there are other classes of bugs to track with tags, please discuss them with the SecurityTeam first.

Triage

See Security Team Bug Triage.

Known Bugs

Many security issues are tracked only by their CVE identifier and may not yet have an Ubuntu bug opened for them. The Ubuntu CVE tracker contains the list of open security issues for packages in main/restricted and for universe/multiverse.

For completeness, the list of all CVE identifiers can be reviewed.

Non-Bugs

Many common issues come up that may seem to be security design problems, but are actually done intentionally. Please review the Ubuntu Security Policies before reporting a bug in this area.

CategorySecurityTeam CategoryDebugging