DebuggingSecurity

Differences between revisions 13 and 14
Revision 13 as of 2009-02-12 23:40:09
Size: 8697
Editor: c-71-237-255-223
Comment: update wording about unblock physical access
Revision 14 as of 2009-02-12 23:42:47
Size: 8750
Editor: c-71-237-255-223
Comment: link to ust
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
Marking an Ubuntu bug as a "security bug" 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:
Marking an Ubuntu bug as a "security bug" (handled by the [[SecurityTeam|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:

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

To open a security bug, follow the regular bug-filing instructions, but take special note of the "Mark as security issue" check box near the bottom of the form:

security-bug.png

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:

publicly-disclose.png

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

privacy.png

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 SecurityTeam/Audits 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.

Stock Replies

Not Security

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

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 bugs, but are not handled as such. Several classes of issue are not considered bugs in Ubuntu security:

Unblocked Physical Access

While every attempt is made to securely isolate physically local users of a shared computer from one another, the stock Ubuntu installation is not intended to block an attacker with physical access. If this is a priority for your system, it is recommended that you take advantage of hard drive encryption, BIOS passwords, and other mechanisms designed to increase physical access security.

By default, Ubuntu's root user does not have a password. As a result, the "safe" and "recovery" modes (which require console access) will allow root to log in without a password. Since these systems use "sulogin", once a root password has been set, these modes will require the root password to start up. If this is desired, set a password with "sudo passwd root".

Local Denial of Service

The default Ubuntu configuration is designed to handle multiple users sharing resources. Because of this, it is possible for a single user to accidentally (or intentionally) use up all of a shared resource (e.g. CPU time, memory, hard drive space). A common example of this is a "fork-bomb", or filling all available disk space. If resource limits are a priority for your system, please investigate using ulimits and disk quotas to help limit resource over-usage.

Permissive Home Directory Permissions

By default, Ubuntu is designed to allow users to easily share files and help each other. To support this, each user's default home directory is readable by all other users. Private files should be kept in the "Private" sub-directory, where access permissions will limit access by other users. If restrictive home directory permissions are a priority for your system, please investigate the /etc/adduser.conf file for adjusting various settings when creating new users, including the default permission mask for newly created home directories.

Local Network Privacy

There are no open service ports on a default Ubuntu system. The exceptions to this are the DHCP client and mDNS (Avahi). For DHCP and mDNS to work fully, the local hostname is used when handling certain DHCP and mDNS actions. As such, the hostname of a system is not considered private information and is shared with the local network.

By default, user names are not available to the local network. However, they may become shared with the local network when various mDNS-announcement services are enabled (e.g. Rhythmbox Music Sharing, Remote Desktop, etc). As such, it is best to consider individual local user names as public, but the list of all users on a system as private. For this reason, any mechanisms that allow an unauthenticated way to query for a list of all local user names should be considered a security issue.


CategoryDebugging

DebuggingSecurity (last edited 2021-10-15 18:00:06 by sbeattie)