UpdateProcedures

Differences between revisions 29 and 30
Revision 29 as of 2007-11-15 19:26:02
Size: 10104
Editor: mail
Comment:
Revision 30 as of 2007-11-15 19:51:16
Size: 10337
Editor: mail
Comment:
Deletions are marked like this. Additions are marked like this.
Line 92: Line 92:
 0. Look for the next free USN number (format: NNN-S) at [http://www.ubuntu.com/usn]. For a new issue, use the next NNN and S=1. To correct or continue a previous USN (because the previous one was broken or incomplete), keep NNN and increase S. The following instructions assume $USN has been set as desired (e.g. one ran `USN=42-1` for USN 42-1).  0. For a new USN, look at ~kees/usn/NEXT for the USN number (format: NNN-S) to use. Verify it has not been used by checking [http://www.ubuntu.com/usn]. If it is not listed on [http://www.ubuntu.com/usn], then use this USN for the update, and increment ~kees/usn/NEXT to show the next available USN (use the next NNN and S=1). To correct or continue a previous USN (because the previous one was broken or incomplete), keep NNN and increase S without changing ~kees/usn/NEXT. The following instructions assume $USN has been set as desired (e.g. one ran `USN=42-1` for USN 42-1).

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.

Responsibility

The Ubuntu security team (security@ubuntu.com, Launchpad team [https://launchpad.net/people/ubuntu-security ubuntu-security]) is responsible for all issues that affect source packages in Ubuntu main and restricted. Usually timely updates are provided.

The Ubuntu security team also tracks issues in universe and multiverse. It aims to solve vulnerabilities in the current development release by requesting syncs from Debian. Due to lack of manpower, flaws in stable releases and Ubuntu-modified packages are not fixed by ubuntu-security, but the team will provide assistance in releasing updates which are prepared by other developers.

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 [https://lists.grok.org.uk/mailman/listinfo/full-disclosure full-disclosure mailing list] ([http://lists.grok.org.uk/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 [:UbuntuDevelopment#head-86b3c262f4e4b222c867211cb06bb46523c7cc6f:updated package] based on the appropriate released source package or the last security update.

    • 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.
      • In the rare cases when a security update must include a major version update, it should, if possible, go to -proposed first for testing. Any upload by a security team member to -proposed for a security vulnerability will get accepted immediately without ack from ubuntu-sru (similar to how regular security fixes being installed into -updates happen without ack). However, they must still be processed manually, please contact a member of the [https://launchpad.net/~ubuntu-archive/+members Ubuntu Archive team].

    • Prefer packaging the changes as [:PackagingGuide/PatchSystems:proper patches]

  3. Properly test that the package builds and still works
    • If possible, use publicly available exploits and test cases to verify that the bug is fixed
    • In all cases, verify that the package still functions properly
  4. 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. In the case where two Ubuntu releases have the same version number for the package, append the appropriate Ubuntu release version followed by a '.1'.
    • =====================  ===================
      ''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-2build1            2.0-2ubuntu0.1
      2.0                    2.0-0ubuntu0.1
      2.0-2 in two releases  2.0-2ubuntu0.5.04.1 and 2.0-2ubuntu0.5.10.1
      =====================  ===================
  5. Create an appropriate changelog entry with a verbose description of the changes and CVE/CAN and other bug number references. Set the distribution to dapper-security (or edgy-security or whatever) and use a version number that indicates a security update. If there is a corresponding LaunchPad bug open for the issue, include a (Fixes LP: #...) section to auto-close the bug.

    • Template:

      • [package] ([version]) [release]-security; urgency=low
        
          * SECURITY UPDATE: [what can happen when it misbehaves]
          * [patches added, files changed]: [what changed].  [patch origin]. (Fixes LP: #...)
          * References
            [bug or patch URL if useful]
            [CVEs if available]

      Real-world Examples:

      • rpm (4.4.1-5ubuntu2.1) dapper-security; urgency=low
        
          * SECURITY UPDATE: heap overflow in query report could lead to arbitrary
            code execution.
          * Add 'debian/patches/99_query_heap_protection.diff': validate message
            length.  Patch from upstream CVS, applied inline.
          * References
            https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212833
            CVE-2006-5466
        openldap2.2 (2.2.26-5ubuntu2.2) dapper-security; urgency=low
        
          * SECURITY UPDATE: Denial of service possible with a crafted remote
            LDAP BIND request due to an assert failure.
          * libraries/libldap/getdn.c: check for string end conditions, as done
            in upstream CVS.
          * References
            CVE-2006-5779
  6. 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.
  7. Publish the debdiff in Launchpad for inspection.
  8. Updates prepared directly by the security team should be peer-reviewed. Updates prepared by others will be peer-reviewed by a security team member.
  9. For input on patches, send a note to the MOTU mailing list ([http://lists.ubuntu.com/mailman/listinfo/ubuntu-motu ubuntu-motu@lists.ubuntu.com]) with a reference to the bug where the debdiff is filed. The security team will upload it at the appropriate time.

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

  11. If the package is in "main" or "restricted", try to write an appropriate "Details" section for an Ubuntu SecurityNotification.

Releasing an update

(For members of the Ubuntu security team)

  1. Notification about failed builds should be automatically sent to security@ubuntu.com.

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

  3. Run helena to display the pending packages.

  4. Once builds for all supported architectures have finished, gather the changes files: PKGS=$(ls yourpackage*changes)

  5. Upload builds to local archive, by running amber 0 $PKGS. (This will also generate an old-style SecurityNotification template). If you built several versions of the package, make sure to push them all out at once, otherwise they will stay in the queue. Optionally append option -n for a dry-run. Answer 'y' to Continue. IMPORTANT: Answer "N" to "Upload to main archive?" question.

  6. After local archive upload, the changes files will have moved to jackass:/srv/ftp.no-name-yet.com/queue/done. cd to this directory.

  7. Verify that there will be no version collision by running ~kees/bin/check-upload -s found $PKGS. If any non-orig files are already found, new versions will need to be prepared before continuing.

  8. Upload to the main soyuz archive by running ~kees/bin/merged-upload $PKGS.

  9. For a new USN, look at ~kees/usn/NEXT for the USN number (format: NNN-S) to use. Verify it has not been used by checking [http://www.ubuntu.com/usn]. If it is not listed on [http://www.ubuntu.com/usn], then use this USN for the update, and increment ~kees/usn/NEXT to show the next available USN (use the next NNN and S=1). To correct or continue a previous USN (because the previous one was broken or incomplete), keep NNN and increase S without changing ~kees/usn/NEXT. The following instructions assume $USN has been set as desired (e.g. one ran USN=42-1 for USN 42-1).

  10. Run ~kees/bin/generate-usn $USN $PKGS > ~/usn.sh to create a USN template script.

  11. Edit ~/usn.sh to include a correct title, summary, action, description, and then limit the binary list to only those affected by the USN. Leave all URLs as-is. Have the description proofread by somebody else.

  12. Run bash ~/usn.sh to populate the USN database with the new USN details.

  13. Run ~kees/bin/send-usn-email $USN to generate the template email, which is sent to security@ubuntu.com.

  14. Wait until the packages are actually in the archive; Soyuz security uploads are accepted by LP hourly at :55, and should usually appear on security.ubuntu.com about 40 minutes after that. (Note that uploads at UTC 0355 will skip the 0403 publication run due to the Contents generation job.)

  15. Run ~kees/bin/check-upload $PKGS to verify that the packages have arrived in the archive.

  16. If a re-upload is needed, use ~kees/bin/merged-upload $PKGS.

  17. GPG sign and send the USN email to ubuntu-security-announce@lists.ubuntu.com; CC bugtraq@securityfocus.com and full-disclosure@lists.grok.org.uk.

  18. Approve the USN mail on [https://lists.ubuntu.com/mailman/admindb/ubuntu-security-announce]. Ensure to reject duplicate mails from you (some list subscribers bounce mails back unmodified).

  19. Create a new USN page for this USN via https://www-admin.ubuntu.com/. Copy&paste the USN email text, but without the file list, wrapped in a "div id=usn" tag, include the cve file path, and a list of all the CVEs.

  20. Copy the updated USN database by running sudo -u ubuntu-security /home/kees/bin/get-usn-db on rookery and ~kees/bin/put-usn-db on jackass.

  21. For large updates (OOo, firefox, kernel, kdebase), ping cjwatson/pitti about doing a pocket-copy from -security to -updates to help reduce the load on security.archive.com.


CategoryProcess

SecurityTeam/UpdateProcedures (last edited 2019-09-16 14:57:57 by seth-arnold)