FixingCVEs

Differences between revisions 14 and 15
Revision 14 as of 2011-02-16 18:31:12
Size: 6045
Editor: brad-figg
Comment:
Revision 15 as of 2011-02-16 18:34:26
Size: 6090
Editor: brad-figg
Comment:
Deletions are marked like this. Additions are marked like this.
Line 24: Line 24:
    {{{
    create-cve-tracker --cve=2010-4079
      }}}
   {{{
   create-cve-tracker --cve=2010-4079
   }}}
Line 28: Line 28:
   1. As you work the bug on each distro series indicate in the appropriate task the relevance of the patch to that series. For example, if the bug has already been applied, mark that series task as "Fix Released". If the patch is not relevant to that series, mark the task as "Invalid". If the patch is valid and has not been applied already (via a stable upstream release) then mark the status as "In Progress", mark the importance as the same as the CVE priority and assign yourself to the task.    1. As you work the bug on each distro series indicate in the appropriate task the relevance of the patch to that series. For example:
     * I
f the bug has already been applied, mark that series task as "Fix Released".
     *
If the patch is not relevant to that series, mark the task as "Invalid".
     *
If the patch is valid and has not been applied already (via a stable upstream release) then:
       1. M
ark the status as "In Progress"
       1. M
ark the importance as the same as the CVE priority
       1. A
ssign yourself to the task.

This document is intended to describe the process the Kernel Team uses to work on CVEs. It does not attemp to explain what a CVE is.

Where are the CVEs that need to be worked on?

There are several places where you can find a CVE to work upon. They are:

Security Team

The Security Team's official page of kernel specific CVEs. This page is semi-automatically updated by members of the Security Team. Contact Kees Cook for more information

Kernel Team

This page shows which CVEs are already beeing worked on by someone on the kernel team. It also shows the current progress on the CVE. It is the responsibility of every member of the Kernel Team to keep this spreadsheet up-to-date.

Cookbook

  1. Pick a CVE to work on.
    1. Go to the kernel team's CVE spreadsheet, pick out a CVE to work on and put your username in the "Assignee" column, next to the CVE you picked.

  2. Save the patch to a file.
    1. Go to the cve tracker page (http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html)

    2. Follow the CVE link in the left column for the CVE you are working to the details page.
    3. Follow the link for "Patches: Upstream:" to the upstream git web commit
    4. Click the "patch" link in the top part of the page.
    5. Select "Save As" from your browser and save the patch.
  3. Create a LP bug
    1. Use the "create-cve-tracker" tool. Note the cve-id is "20xx-xxxx", it does not include the "CVE-" text. For example:
         create-cve-tracker --cve=2010-4079
    2. The bug description should be updated with information taken from the patch commit description.
    3. As you work the bug on each distro series indicate in the appropriate task the relevance of the patch to that series. For example:
      • If the bug has already been applied, mark that series task as "Fix Released".
      • If the patch is not relevant to that series, mark the task as "Invalid".
      • If the patch is valid and has not been applied already (via a stable upstream release) then:
        1. Mark the status as "In Progress"
        2. Mark the importance as the same as the CVE priority
        3. Assign yourself to the task.
  4. Modify the patch
    1. Add the buglink to the patch
    2. Add your sob to the patch
    3. Add the CVE number to the Subject line
    4. Add the CVE number to the bug comment body above the buglink
    5. Add the upstream commit from which the patch was either cherry-picked or backported above your s.o.b.
    6. Add a comment if the patch was accepted into one or more stable kernels.




  1. Create a Launchpad Bug for the targeted CVE.
    • Use the CVE id as the title for the bug.
    • Use the Description from the CVE tracker link as the bug description.
    • Add the tag: "kernel-cve-tracker"
  2. Add the Launchpad Bug link to the kernel team's CVE spreadsheet in the Bug Number column for the CVE.

STEAM='lp:~ubuntu-security/ubuntu-cve-tracker/master'
KTEAM='lp:~canonical-kernel-team/ubuntu-cve-tracker/kernel-team'

To create the branch:
* bzr branch $KTEAM

In tracker branch (this syncing should probably be scripted):
* bzr pull $KTEAM
* bzr commit -m "Saving local changes"
* bzr push $KTEAM
* bzr missing -q --theirs-only --line $STEAM | tee ../msg
  If ../msg is not empty
  * bzr merge $STEAM
  * bzr commit -m "$(cat ../msg)"
  * bzr push $KTEAM

After changing the anything in an active/CVE-* file
!! WARNING: bzr includes *all* files changed in the branch dir to the commit
* bzr commit -m "<this is my message to the world>"
* bzr push $KTEAM

Useful for cleaning up previous commit (commit undone, changes not)
* bzr uncommit

Notes to be cleaned up:

  1. Save the patch to a file.
    • Go to the cve tracker page (http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html)

    • Follow the CVE link in the left column for the CVE you are working to the details page.
    • Follow the link for "Patches: Upstream:" to the upstream git web commit
    • Click the "patch" link in the top part of the page.
    • Select "Save As" from your browser and save the patch.
  2. Modify the patch
    • Add the buglink to the patch
    • Add your sob to the patch
    • Add the CVE number to the Subject line
    • Add the CVE number to the bug comment body above the buglink
    • Add the upstream commit from which the patch was either cherry-picked or backported above your s.o.b.
    • Add a comment if the patch was accepted into one or more stable kernels.
  3. Create a LP bug
    • Summary is the CVE id: "CVE-2010-XXXX"
    • Mark the bug as a security bug
    • Further information is taken from the patch commit description.
    • Add the tag: "kernel-cve-tracker"
    • Add "Link to CVE"
    • Nominate for all supported releases.
      • If the patch has already been applied to a release, mark that task "fixed-released"
      • If the patch is not needed for a particular release it should be marked "invalid"
      • For each release that the patch applies to:
        • Set status to "Inprogress"
        • Set Importance to "Low"
        • Set "Assigned to" to yourself
    • After applying the patch, add the patch as an attachment to the bug.

Topic branches typically get CVE updates whenever they are rebased against master. For those branches that are not normally rebased against master (such as ti-omap4), then CVEs must be extracted more or less manually from the master branch. Since those patches have already been vetted on the kernel team mailing list, a second round of acknowledgements is not required if they apply cleanly.

Kernel/Dev/FixingCVEs (last edited 2011-05-18 22:25:50 by brad-figg)