Ubuntu Wiki

While handling a security update, one must follow these steps before moving on to publication.

Research

1. Collect as much information about the vulnerability as possible. Use the CVE database, the full-disclosure mailing list (archive), the 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. If not present, please file a bug in Launchpad, add CVE references to the bug using the 'Link to CVE' functionality in Launchpad, and add the findings of your research.

Packaging

To fix a vulnerable package, you must patch it and update the packaging for upload. Certain packages require special handling, please see SecurityTeam/PublicationNotes for handling them.

Preparing a patch

1. When preparing an updated package, always base it on the latest approved version of the source package for the release in the archive. For example, if apache2 needs an update in Ubuntu 8.04 LTS, and the release version in hardy is 2.2.8-1, the version in hardy-security is 2.2.8-1ubuntu0.3 and the version in hardy-updates is 2.2.8-1ubuntu0.4, then you would base your updated package on 2.2.8-1ubuntu0.4 in hardy-updates. See the security team FAQ for more information.

2. 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). IMPORTANT: An update that first goes through -proposed should not simply be pocket copied to -updates or -security. It should instead be version bumped with a no change rebuild in the -security queue (this is to avoid dependencies that are only in -updates not being satisfiable when only -security is enabled). There are cases where it may be acceptable to do a pocket copy, but it must be shown that people without -updates installed won't be adversely effected.

   • In some cases, source packages may fail to build (FTBFS). This is usually only seen when packages haven't been updated between different releases. A patch may be included to fix a FTBFS, as long as it is properly documented in the changelog.

3. Prefer packaging the changes as proper patches. When the patch system supports it, please follow the Patch Tagging Guidelines and include as much information as possible. If the package does not support patch tagging, please include this information in the changelog (see below for changelog formatting).

Update the packaging

If you are new to packaging in Ubuntu, you might want to review our Packaging Guide. Security updates typically follow a specific convention that is expected by our users tools. In addition to following good packaging techniques, you will also need to:

1. Update the Maintainer field.

2. 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'.

   • Please be careful. Security updates must have a version number higher than any version that was in the archive for that release. This means you must check the release pocket, the proposed pocket and the updates pocket (see SecurityTeam/FAQ#Repositories for details). Eg, if package foo in Ubuntu 8.04 LTS had version 0.1-2.1 in hardy-proposed, the version for a hardy-security update must be higher (eg, 0.1-2.2 in this example), even if that version was later rejected. Also, if the version is still in proposed, still use a higher version number, but put a comment in the corresponding LP bug for the proposed upload that it will be superseded by the security update, and add the following text to the changelog of the security update:

     •   * this update does not include the changes from <proposed version> as included in 
           <release>-proposed

   • Version examples:

     • ====================================  ===================
       ''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.0ubuntu0.1
       2.0-2 in two releases                 2.0-2ubuntu0.11.10.1 and 2.0-2ubuntu0.12.04.1
       2.0-2ubuntu1 in two releases          2.0-2ubuntu1.11.10.1 and 2.0-2ubuntu1.12.04.1
       2.0-2 in release and devel            2.0-2ubuntu0.1 and 2.0-2ubuntu1 (devel can be synced)
       2.0-2ubuntu1 in release and devel     2.0-2ubuntu1.1 and 2.0-2ubuntu2 (devel can be synced)
       2.0-2 in multiple releases and devel  2.0-2ubuntu0.11.10.1, 2.0-2ubuntu0.12.04.1, and
                                             2.0-2ubuntu1 (devel cannot be synced)
       ====================================  ===================

   • In the rare case of a new upstream release being pushed to all stable releases (substitute for 12.04 in the version string):

     NOTE: This is for an upstream only update, not a backport of the development release package

     • =============  ================ ====================
       ''Previous''   ''New upstream'' ''Security update''
       2.0-2           3.0             3.0-0ubuntu0.12.04.1
       2.0-2ubuntu2    3.0             3.0-0ubuntu0.12.04.1
       2.0-2ubuntu2.1  3.0             3.0-0ubuntu0.12.04.1
       2.0-2build1     3.0             3.0-0ubuntu0.12.04.1
       =============  ================ ====================

   • In a very rare case where you upgrade the version of a package and it cause any regression, you'll need to downgrade to the previous version. e.g: xenial version is 2.3.73 and you upgrade it to 2.3.79 (the bionic version). To downgrade you need to do some ugly trick as: 2.3.79really2.3.73 on the versioning. Make sure it sorts greater than xenial version you're reverting and less than the bionic version. Also, keep in mind the bionic version will probably be needed to be increased as a no-change version update. A real case example: intel-microcode.

3. Create an appropriate changelog entry with a verbose description of the changes, CVE/CAN references, and other appropriate bug number references. Set the distribution [release]-security, e.g. lucid-security or precise-security, and use a version number that indicates a security update. (Note that "urgency" is not used in Ubuntu, so it should just remain "low".) If there is a corresponding LaunchPad bug open for the issue, include a (LP: #...) section to auto-close the bug.

   • Template:

     [package] ([version]) [release]-security; urgency=low
     
      * SECURITY UPDATE: [how bad people could get you] (LP: #num).
        - changed/or/added/file1: [how it was fixed], [thanks to original author]
        - changed/or/added/file2: [how it was fixed], [thanks to original author]
        - http://path/to/patch/source/when/this/url/is/not/in/the/new/debian/patch
        - CVE-YYYY-NNNN
      * ...

     Examples:

     ruby1.8 (1.8.4-1ubuntu1.6) dapper-security; urgency=low
     
       * SECURITY UPDATE: denial of service via resource exhaustion in the REXML
         module (LP: #261459)
         - debian/patches/917_CVE-2008-3790.patch: adjust rexml/document.rb and
           rexml/entity.rb to use expansion limits. Based on upstream patch.
         - CVE-2008-3790
       * SECURITY UPDATE: integer overflow in rb_ary_fill may cause denial of
         service (LP: #246818)
         - debian/patches/918_CVE-2008-2376.patch: adjust array.c to properly
           check argument length. Based on upstream patch.
         - CVE-2008-2376

     mplayer (2:1.0~rc1-0ubuntu13.3) gutsy-security; urgency=low
     
       * SECURITY UPDATE: Multiple integer underflows in MPlayer 1.0_rc2 and
         earlier allow remote attackers to cause a denial of service
         (process termination) and possibly execute arbitrary code via a
         crafted video file that causes the stream_read function to read or
         write arbitrary memory. (LP: #279030)
         - libmpdemux/demux_real.c: Address various integer underflows. Patch from
           oCert.org
         - http://svn.mplayerhq.hu/mplayer/trunk/libmpdemux/demux_real.c?r1=27314&r2=27675
         - CVE-2008-3827

Update the packaging for partner packages

In emergencies, the Ubuntu Security team may need to upload or sponsor updates to the Canonical archive. When preparing packaging, please follow the above with the following exceptions:

• Verify debian/control prepends 'partner/' to all Sections (this should already be done in the packaging you are updating). Eg:

  Source: sun-java6
  Section: partner/java
  ...
  Package: sun-java6-jre
  Section: partner/java
  ...

• Verify the distribution name in debian/changelog does not specify a pocket. Eg, a valid entry would look something like:

  sun-java6 (6.26-2lucid1) lucid; urgency=low
  ...

Testing

Testing an update is important. At a minimum, be sure to:

1. build in a clean build environment
2. verify the package still installs
3. verify the package upgrades cleanly
4. verify the package still functions properly
5. use public exploits and Proof of Concept(s) (PoC) (if available) to verify the bug is fixed

Most people will want to use Pbuilder for building their packages since it is easy to setup and use. If you are doing a lot of Ubuntu development, you might be interested in sbuild (and optionally umt, which uses sbuild) since it more closely mimics the official Ubuntu builders.

Testing can usually be performed in several ways:

• on a native, live system (simplest, but not a clean environment)
• via a live CD (clean environment, but slow to use)

• in a chroot/namespace (clean environment, needs space, but easy to setup with sbuild. May not be appropriate for all software)

• in a virtual machine (clean environment, needs space, typically recommended option)

For additional techniques:

• See QA Regression Testing for scripts and techniques on testing packages.

• Use existing testing techniques for the package, eg:
  • build tests
  • test suites
• Compare build logs

• Compare binary packages (use debcompare from Security Tools)

Submission

Follow the procedures outlined in SecurityTeam/SponsorsQueue#Notes for Contributors and please indicate the testing performed. If you are not an Ubuntu developer and/or are unfamiliar with submitting patches to Ubuntu, you also may wish to read about the SponsorshipProcess.

Please also consider:

1. writing an appropriate "Details" section for an Ubuntu Security Notification (USN) if the package is in "main" or "restricted".

2. sending the package interdiff to the Debian BTS if Debian does not yet have a fix by following Debian/Bugs and Debian/Usertagging (if you use submittodebian, it will take care of all that for you), CC'ing security@debian.org, and adding the Debian bug to the Launchpad bug by using the 'Also affects distribution' functionality in Launchpad.

CategorySecurityTeam CategoryProcess