SecurityUpdateProcedures

Ubuntu security updates

Issues that warrant a security update

We only fix bugs in our stable releases which truly affect overall system security, i. e. which enable an attacker to circumvent the permissions configured on the system, or are a threat to the user's data in any way. Most common examples:

• Buffer overflow in a server process which allows to crash it (denial of service) and/or to execute attacker provided code (privilege escalation).
• Insecure temporary file handling which allows race condition and symlink attacks to delete unrelated files with the invoker's privileges.
• Non-working security-relevant configuration options (e. g. iptables would allow packets which should be blocked, or a server's ACL option does not do the right thing).
• Less critical bugs (like Denial of Service vulnerabilities in instant messengers or email applications) are also fixed usually, but with lower priority.

Preparing an update

1. Collect as much information about the vulnerability as possible. Use the [http://cve.mitre.org/cve CVE database], the [http://www.securityfocus.com/archive/1 BugTraq] and [http://lists.netsys.com/mailman/listinfo/full-disclosure full-disclosure mailing list] ([http://lists.netsys.com/pipermail/full-disclosure/ archive]), the [http://bugs.debian.org Debian BTS], upstream bug tracking system, upstream revision control systems, and any other source to collect CAN/CVE numbers, causes, impacts, patches, and possible workarounds.

2. Prepare an updated package based on the appropriate released source package or the last security update.
3. Make only the minimum changes necessary to fix the bug. This is crucial both for the review process and to avoid introducing bugs or unexpected behavioural changes
4. Prefer packaging the changes as proper patches
5. Properly test that the package builds and still works
6. If possible, use publicly available exploits and test cases to verify that the bug is fixed
7. In all cases, verify that the package still functions properly
8. Determine the version number to be used for the package. This requires some care, because it must be newer than the version being patched, but earlier than any version in the development branch. In general, you should add "0.1" to the Ubuntu revision, similar to Debian's source NMU version numbers:

==================== ===================
''Previous version'' ''Security update''
2.0-2                2.0-2ubuntu0.1
2.0-2ubuntu2         2.0-2ubuntu2.1
2.0-2ubuntu2.1       2.0-2ubuntu2.2
2.0                  2.0-0ubuntu0.1
==================== ===================

1. Create an appropriate changelog entry with a verbose description of the changes and CVE/CAN and other bug number references. Set the distribution to warty-security (or hoary-security or whatever) and use a version number that indicates a security update.

Real-world example:

    groff (1.18.1.1-1ubuntu0.1) warty-security; urgency=high

     * SECURITY UPDATE: fix insecure temporary file creation
     * contrib/groffer/groffer.sh: use mktemp -d to securely create temporary
       directory; originally, a process id based approach was used (predictable,
       vulnerable to race conditions) and the directory was allowed to exist
       previously (vulnerable to overwrite user files)
     * References:
       CAN-2004-0969
       http://bugs.debian.org/278265

1. Generate a debdiff against the previous package version, read it to verify that you only did minimal changes and that the changes are indeed correct. Publish the debdiff in Ubuntu's bug database for inspection.
2. Updates prepared directly by the security team should be peer-reviewed. Updates prepared by others will be peer-reviewed by a security team member.

3. Send a notification to the Ubuntu security team (security@ubuntulinux.org) with a reference to the bug where the debdiff is filed. The security team will upload it at the appropriate time.

4. If Debian does not yet have a fix, send the package interdiff to the Debian BTS (create a new bug if necessary), CC'ing security@debian.org

5. Try to write an appropriate "Details" section for a SecurityNotification.

Releasing an update

(For members of the Ubuntu security team)

1. Notification about failed builds should be automatically sent to security@ubuntulinux.org.

2. Run helena to display the pending packages.

3. The finished builds appear in jackass:/srv/ftp.no-name-yet.com/queue/accepted/. cd to this directory.

4. Run amber 42-1 yourpackage*.changes to publish the source package and all source debs to the archive and generate a template SecurityNotification for USN-42-1. If you uploaded several versions of the package, make sure to amber them all, otherwise they will stay in the queue. Optionally append option -n for a dry-run.

5. The template SecurityNotification will be sent to security@ubuntulinux.org

6. Fill the template, have it proofread by somebody and send it to ubuntu-security-announce@lists.ubuntu.com; CC bugtraq@securityfocus.com and full-disclosure@lists.netsys.com.