UpdateProcedures

Differences between revisions 75 and 116 (spanning 41 versions)
⇤ ← Revision 75 as of 2008-10-09 16:33:40 →
Size: 20061
Editor: pool-71-114-229-100
Comment: add another versioning example
← Revision 116 as of 2019-09-16 14:57:57 → ⇥
Size: 4804
Editor: seth-arnold
Comment: remove ubuntu touch note
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from SecurityUpdateProcedures
Line 14: Line 15:
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 (security@ubuntu.com, Launchpad team [[https://launchpad.net/people/ubuntu-security|ubuntu-security]]) is responsible for all issues that affect source packages in [[https://wiki.ubuntu.com/SecurityTeam/FAQ#Official%20Support|Ubuntu main and restricted]] and will work with upstreams (Canonical and other), distributions and developers in providing security fixes to Ubuntu.
Line 16: Line 17:
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. The Ubuntu Security team also tracks issues in universe and multiverse and at their discretion may request a sync from Debian to solve vulnerabilities in packages in the current development release. Patches for flaws in packages from universe and multiverse for stable releases or for the development release when a sync from Debian is deemed too intrusive should be prepared by community members.
Line 18: Line 19:
<<Anchor(Prepare)>>
Line 21: Line 21:
 0. 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.
 0. Prepare an [[UbuntuDevelopment#Packaging|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). '''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.
  * Prefer packaging the changes as [[PackagingGuide/PatchSystems|proper patches]]. When the patch system supports it, please follow [[UbuntuDevelopment/PatchTaggingGuidelines|PatchTaggingGuidelines]] and include as much information as possible.
  * Update the [[DebianMaintainerField|Maintainer field]] only if working on Feisty or newer.
 0. Properly test that the package builds and still works. You can refer to [[http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files|QA Regression Testing]] for scripts and techniques on testing packages.
  * 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
 0. 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
2.0-2ubuntu1 in two releases 2.0-2ubuntu1.5.04.1 and 2.0-2ubuntu1.5.10.1
============================ ===================
}}}
 0. Create an appropriate changelog entry with a verbose description of the changes and CVE/CAN and other bug number references. Set the distribution '''[release]-security''', e.g. '''dapper-security''' or '''edgy-security''', and use a version number that indicates a security update. 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		 Preparing an update requires a lot of effort and attention to detail. Ubuntu has millions of users who expect a very high level of stability in their system. To achieve a high level of quality, the process has be broken down into the following stages:
Line 48: Line 23:
 * SECURITY UPDATE: [how the bad guys 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
 * ...
}}}		  * [[SecurityTeam/UpdatePreparation#Research|Research]]
 * [[SecurityTeam/UpdatePreparation#Packaging|Packaging]]
 * [[SecurityTeam/UpdatePreparation#Testing|Testing]]
 * [[SecurityTeam/UpdatePreparation#Submission|Submission]]
Line 56: Line 28:
  '''Examples:'''
  {{{
ruby1.8 (1.8.4-1ubuntu1.6) dapper-security; urgency=low		 The [[https://wiki.ubuntu.com/MOTU|MOTU]] and [[https://launchpad.net/~motu-swat|MOTU Swat]] developers are available to answer questions and provide assistance in preparing updates. The [[https://launchpad.net/people/ubuntu-security|Ubuntu Security]] team will process updates from community and provide assistance as needed.
Line 60: Line 30:
  * 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		 '''Remember''': People can help with any stage of the process, so don't be shy-- get involved!
Line 74: Line 32:
  * 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
}}}
 0. 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.
 0. Publish the debdiff in Launchpad for inspection, set the status of the bug to 'In Progress' and make sure that 'ubuntu-security' is subscribed to the bug.
 0. Please indicate the testing performed. Testing might include (but is not limited to) build tests, test suites, PoC, ABI changes, and testing the patched code so that it introduces no regressions. For more information on testing, please see [[https://launchpad.net/qa-regression-testing|QA Regression Testing]].
 0. If not present, please add CVE references to the Launchpad bug using the 'Link to CVE' functionality in Launchpad
 0. Updates prepared directly by the security team should be peer-reviewed. Updates prepared by others will be peer-reviewed by a security team member.
 0. 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.
 0. If Debian does not yet have a fix, send the package interdiff to the Debian BTS by following [[https://wiki.ubuntu.com/Debian/Bugs|Debian/Bugs]] and [[https://wiki.ubuntu.com/Debian/Usertagging|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.
 0. If the package is in "main" or "restricted", try to write an appropriate "Details" section for an Ubuntu SecurityNotification.
Line 95: Line 35:
(For members of the Ubuntu security team) Only members of the [[https://launchpad.net/~ubuntu-security|Ubuntu Security team]] can publish security updates into the security pocket for a given Ubuntu release. Updates are usually uploaded to and published from the private [[https://launchpad.net/~ubuntu-security/+archive/ppa|Ubuntu Security team PPA]], though other teams may have their own PPAs that updates may be pulled from.
Line 97: Line 37:
=== Upload/Build/Publish ===
  
 0. Upload the updated source packages via dput. Notification about failed builds should be automatically sent to `security@ubuntu.com`. Can use `tail -f /srv/ftp.no-name-yet.com/queue/REPORT` to see when the packages get accepted.
 0. The finished builds appear in `jackass:/srv/ftp.no-name-yet.com/queue/accepted/`. `cd` to this directory.
 0. Run `helena` to display the pending packages.
 0. Once builds for all supported architectures have finished (e.g. {{{~kees/bin/check-build firefox}}}), gather the changes files: `PKGS=$(ls yourpackage_*changes)`
 0. 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.
 0. After local archive upload, the changes files will have moved to `jackass:/srv/ftp.no-name-yet.com/queue/done`. `cd` to this directory.
 0. Verify that there will be no version collision by running `~kees/bin/check-upload-from-changes -s found $PKGS` (this should say '0% found'). If any non-orig files are already found, new versions will need to be prepared before continuing.
 0. Upload to the main soyuz archive by running `~kees/bin/merged-upload $PKGS`. (This can be run again at a later time if soyuz publication fails.) For kernel updates, inform #canonical-sysadmin that an update will be published soon.		 The Ubuntu Security team publishes updates from the following:
|| '''Team''' || '''Location''' || '''Availability''' || '''Publication Procedure''' ||
||[[https://launchpad.net/~ubuntu-security|Ubuntu Security]]||[[https://launchpad.net/~ubuntu-security/+archive/ppa/+packages|Ubuntu Security PPA]]||private||[[SecurityTeam/UpdatePublication|UpdatePublication]]||
||[[https://launchpad.net/~ubuntu-security-proposed|Ubuntu Security Proposed]]||[[https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages|Ubuntu Security Proposed PPA]]||public||[[SecurityTeam/UpdatePublication|UpdatePublication]]||
||[[https://launchpad.net/~ubuntu-mozilla-security|Mozilla Security]]||[[https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages|Mozilla Security PPA]]||public||[[https://wiki.ubuntu.com/ArchiveAdministration#Publishing%20mozilla%20security%20uploads%20from%20the%20ubuntu-mozilla-security%20public%20PPA|ArchiveAdministration]]||
Line 108: Line 43:
=== Announce Publication ===

(for main/restricted publications)

 0. Assign a USN (format is NNN-S, and the following instructions assume $USN has been set as desired):
  0. For a new issue, run {{{USN=$(~kees/bin/get-next-usn)}}} (this reads from and increments ~kees/usn/NEXT)
  0. For an old issue that needs correction or continuation, start with the issue's original USN, keep NNN and increase S. (e.g. original issue was 42-1, updated USN will be 42-'''2''').
  0. For a new issue that affects different software with identical CVEs, run {{{USN=$(~kees/bin/get-next-usn)}}} for the first source package, and then keep NNN and increase S for each additional source package. (e.g. CVE-2008-1693 affected both poppler and koffice, so 603-1 was used for poppler and 603-2 was used for koffice). Please note that different versions of the same software (e.g. emacs21 and emacs22) should not do this, but instead use a single USN with S=1.
 0. Run `~kees/bin/generate-usn $USN $PKGS > ~/new-usn.sh` to create a USN template script.
 0. Edit `~/new-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.
 0. Run `bash ~/new-usn.sh` to populate the USN database with the new USN details.
 0. Run `~kees/bin/send-usn-email $USN` to generate the template email, which is sent to `security@ubuntu.com`.
 0. 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.) Run `~kees/bin/check-upload $USN` to verify that the packages have arrived in the archive.
 0. Once packages are in the archive, 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`.
 0. 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).
 0. 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.
 0. 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.
 0. For large updates (OOo, firefox, kernel, kdebase), ping someone from ArchiveAdministration about doing a pocket-copy from -security to -updates to help reduce the load on security.archive.com.
 0. Check for any outstanding LP bugs tied to the CVEs that are resolved with the USN. [[https://bugs.launchpad.net/bugs/cve/YYYY-NNNN]]

=== Upload/Build/Publish (SiS) ===
  
 0. Upload the updated source packages via dput to each release's security PPA target. Notification about failed builds should be automatically sent to `security@ubuntu.com`.
   {{{
[security-dapper]
fqdn = ppa.launchpad.net
incoming = ~ubuntu-security/ubuntu/dapper
login = anonymous

[security-feisty]
fqdn = ppa.launchpad.net
incoming = ~ubuntu-security/ubuntu/feisty
login = anonymous

[security-gutsy]
fqdn = ppa.launchpad.net
incoming = ~ubuntu-security/ubuntu/gutsy
login = anonymous

[security-hardy]
fqdn = ppa.launchpad.net
incoming = ~ubuntu-security/ubuntu/hardy
login = anonymous
}}}
 0. Wait for the finished builds on all supported architectures to finish and appear at the [[https://edge.launchpad.net/~ubuntu-security/+archive|Ubuntu Security PPA]]. (command line tool needed!)
 0. Request [[ArchiveAdministration#Unembargoing security uploads|unembargoing]] from an [[https://edge.launchpad.net/~ubuntu-archive/+members|archive admin]] (ssh forced-command needed!)

=== Announce Publication (SiS) ===

(for main/restricted publications)

 0. Assign a USN (format is NNN-S, and the following instructions assume $USN has been set as desired):
  0. For a new issue, run {{{USN=$(~kees/bin/get-next-usn)}}} (this reads from and increments ~kees/usn/NEXT)
  0. For an old issue that needs correction or continuation, start with the issue's original USN, keep NNN and increase S. (e.g. original issue was 42-1, updated USN will be 42-'''2''').
  0. For a new issue that affects different software with identical CVEs, run {{{USN=$(~kees/bin/get-next-usn)}}} for the first source package, and then keep NNN and increase S for each additional source package. (e.g. CVE-2008-1693 affected both poppler and koffice, so 603-1 was used for poppler and 603-2 was used for koffice). Please note that different versions of the same software (e.g. emacs21 and emacs22) should not do this, but instead use a single USN with S=1.
 0. Run `~kees/bin/sis-pull-gen $USN > ~/new-usn.sh` to create a USN template script. This will prompt you to run the appropriate `sis-changes` command locally and paste in the changes and dsc file URL. The script `sis-changes` is in `ubuntu-cve-tracker` bzr. Each version of a given source package must be specified: `scripts/sis-changes ubuntu-security SRCPKG VERSION VERSION...`
 0. Edit `~/new-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.
 0. Run `bash ~/new-usn.sh` to populate the USN database with the new USN details.
 0. Run `~kees/bin/send-usn-email $USN` to generate the template email, which is sent to `security@ubuntu.com`.
 0. 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.) Run `~kees/bin/check-upload $USN` to verify that the packages have arrived in the archive.
 0. Once packages are in the archive, 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`.
 0. 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).
 0. 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.
 0. 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.
 0. For large updates (OOo, firefox, kernel, kdebase), ping an [[https://edge.launchpad.net/~ubuntu-archive/+members|archive admin]] about doing a [[ArchiveAdministration#Copying security uploads to updates|pocket-copy from -security to -updates]] to help reduce the load on security.archive.com. (ssh forced-command needed!)
 0. Check for any outstanding LP bugs tied to the CVEs that are resolved with the USN. [[https://bugs.launchpad.net/bugs/cve/YYYY-NNNN]]
 0. Delete PKGS from Security PPA.		 For packages that have a special publication procedure such as the kernel or Mozilla updates, please also consult SecurityTeam/PublicationNotes.
Line 177: Line 46:


=== Publication of Shared orig.tar.gz Source Packages ===
If a package uses the same orig.tar.gz between releases (eg, dapper, edgy and feisty mozilla-thunderbird all use the same orig.tar.gz), then need to make sure that the first one (in this case, dapper) gets built/published before the others (eg, edgy and feisty). This must happen on both dak and soyuz. Therefore, the order of operations becomes:

 0. Perform all steps of Upload/Build/Publish for the earliest release that uses the shared orig.tar.gz (eg, dapper)
 0. Perform all steps up to but not including the upload to soyuz of Upload/Build/Publish for all other releases that use the shared orig.tar.gz (eg, edgy and feisty)
 0. Wait until the packages for the earliest release that uses the shared orig.tar.gz (eg, dapper) appear on security.ubuntu.com. You can `cd` to `jackass:/srv/ftp.no-name-yet.com/queue/done` and run `~kees/bin/check-upload-from-changes $PKGS` where PKGS contains only the *changes files from the earliest release (eg, dapper). This command should say 100% found.
 0. Once the packages from the earliest release that uses the shared orig.tar.gz (eg dapper) are in the archive, upload packages to soyuz for all other releases that use the shared orig.tar.gz (eg, edgy and feisty)
 0. Continue with announce publication as required.


=== Editing a Published USN ===
 0. Edit the page for this USN via https://www-admin.ubuntu.com/.
 0. Update the USN database on jackass with `~kees/bin/edit-usn NNN-S`, where NNN-S corresponds to the edited USN, eg 582-2.
 0. 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.		 == Sponsoring an update ==
Please review the [[SponsorshipProcess]] and the [[SecurityTeam/SponsorsQueue]].
Line 198: Line 53:
CategoryProcess CategorySecurityTeam CategoryProcess

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 ubuntu-security) is responsible for all issues that affect source packages in Ubuntu main and restricted and will work with upstreams (Canonical and other), distributions and developers in providing security fixes to Ubuntu.

The Ubuntu Security team also tracks issues in universe and multiverse and at their discretion may request a sync from Debian to solve vulnerabilities in packages in the current development release. Patches for flaws in packages from universe and multiverse for stable releases or for the development release when a sync from Debian is deemed too intrusive should be prepared by community members.

Preparing an update

Preparing an update requires a lot of effort and attention to detail. Ubuntu has millions of users who expect a very high level of stability in their system. To achieve a high level of quality, the process has be broken down into the following stages:

The MOTU and MOTU Swat developers are available to answer questions and provide assistance in preparing updates. The Ubuntu Security team will process updates from community and provide assistance as needed.

Remember: People can help with any stage of the process, so don't be shy-- get involved!

Releasing an update

Only members of the Ubuntu Security team can publish security updates into the security pocket for a given Ubuntu release. Updates are usually uploaded to and published from the private Ubuntu Security team PPA, though other teams may have their own PPAs that updates may be pulled from.

The Ubuntu Security team publishes updates from the following:

For packages that have a special publication procedure such as the kernel or Mozilla updates, please also consult SecurityTeam/PublicationNotes.

Sponsoring an update

Please review the SponsorshipProcess and the SecurityTeam/SponsorsQueue.

Regressions

In the case of regressions caused by security updates, please follow the SRU regression policy.

CategorySecurityTeam CategoryProcess

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