pombredanne / git.launchpad.net-ubuntu-cve-tracker- Goto Github PK

------------------
UBUNTU CVE TRACKER
------------------
With the newly revamped ubuntu-cve-tracker, it is much more like Debian's
kernel-sec list where you have these directories:

active/		(CVEs that need attention)
ignored/	(CVEs to be ignored, but want to track with special status/notes)
retired/	(CVEs that have been addressed)

ignored/ also has the file 'not-for-us.txt'.

check-cves pulls down the CVE list from MITRE, cross-references it with
ignored/, ignored/not-for-us.txt and retired/, then adds the new CVEs to
active/.

check-cves can also be used to import Debian DSAs and CVEs that are missing in
Ubuntu (requires secure_testing_path to be properly set up):
./scripts/check-cves --import-missing-debian

Sometimes MITRE and NVD are out of date. The locate_cves.py command can
read emails from an mbox file or a maildir and output a list of CVEs that
referenced that are not included in Ubuntu yet. This output can then be
given to check-cves:
./scripts/check-cves --untriaged <path to locate_cves.py output>

Eg, for Redhat:
  $ w3m -dump_source https://www.redhat.com/archives/rhsa-announce/<year>-<Month>.txt.gz > ~/<year>-<Month>.txt.gz
  $ gzip -d ~/<year>-<Month>.txt.gz
  $ ./scripts/locate_cves.py ~/<year>-<Month>.txt > ~/redhat.mbox
  $ ./scripts/check-cves --untriaged ~/redhat.mbox

Eg, for oss-security:
  <save last month to mbox file, ~/oss-sec_raw.mbox>
  $ ./scripts/locate_cves.py ~/oss-sec_raw.mbox > ~/oss-sec.mbox
  $ ./scripts/check-cves --untriaged ~/oss-sec.mbox

Be sure to apt-get the following:
apt-get install python-configobj python-yaml python-genshi realpath python-progressbar python-pychart subversion

You might also be interested in $UST/utilities/maildir2mbox.py (though
locate_cves.py has maildir support).

CONFIGURATION
-------------
The following values need to be configured in ~/.ubuntu-cve-tracker.conf:

- plb_authentication: path to Firefox LP cookies, used to authenticate
  to LP in various tools that need it (sis-changes).

- secure_testing_path: path to Debian "secure-testing" GIT tree,
  so that CVEs known to Debian can be shown while triaging
  CVEs (check-cves). (get read-only access with:
  'git clone https://salsa.debian.org/security-tracker-team/security-tracker.git')
- packages_mirror: path to archive-layout mirror of supported archs'
  Release and Packages files (used by sis-generate-usn, with the mirror
  created by a tool like packages-mirror).
- usn_tool: path to usn-tool git tree, used to manipulate USN databases
  and for templates (sis-generate-usn).
- usn_storage: path to individual USN pickle database output when
  generating a single USN database before merging into the master USN
  database (sis-generate-usn).
- usn_db_copy: path to copy of master USN database, used when creating
  a template for a USN where "N" != 1 (sis-generate-usn).
- partner_mirror: same as packages_mirror, but for the partner repo.
- debian_mirror: same as packages_mirror, but for Debian testing repo.
- mitre_loc: where to download the MITRE CVE database
- nvd_loc: where to download the NVD database
- kernel_team_tools_path: path to Ubuntu Kernel Team Tools git tree:
  git://kernel.ubuntu.com/ubuntu/kteam-tools.git

Clone the following tree:
https://code.launchpad.net/ubuntu-qa-tools

Then add a sylink from UQT/common/lpl_common.py to UCT/scripts/lpl_common.py:
$ ln -s <path to>/ubuntu-qa-tools/common/lpl_common.py ./scripts/lpl_common.py

Note: if your credentials go out of date and aren't updating, you might want
to move ~/.launchpadlib aside, relogin to Launchpad with your browser and then
re-run a script using lpl_common.py, which should now prompt you in your
browser.

CHECK-CVES
----------

Run like this:
./scripts/check-cves
./scripts/check-cves http://cve.mitre.org/data/downloads/allitems.xml
./scripts/check-cves <file>

Eg:
wget -N http://cve.mitre.org/data/downloads/allitems.xml
./scripts/check-cves ./allitems.xml
for i in $(seq 2004 $(date +%Y)) recent; do wget --quiet -N http://nvd.nist.gov/download/nvdcve-$i.xml; done
./scripts/check-cves ./nvdcve-2*.xml

When running check-cves:
'a'dd 		to add to active/ (see Triaging, below)
'i'gnore 	to add to ignored/not-for-us.txt (see Triaging, below)
's'kip 		don't do anything (will come up next time)

* Note: it may take a few seconds before prompts, as allitems.xml is a large
file.


TRIAGING
--------

*** IMPORTANT ***
ubuntu-cve is PUBLIC. All comments should be professional, and there should be
no embargoed items in ubuntu-cve (until they are made public that is).

If a CVE has been rejected, you can ignore it.

If the CVE is from Microsoft, it generally can be ignored (e.g. Kerberos
packaged in Microsoft), but be sure to watch out for, e.g. CVEs affecting
Samba/SMB.

For CVEs from Android, look for signs that they affect the kernel (though those
can be difficult to pull out if they didn’t link to the upstream kernel
commits) - open the Android webpage for the current month and focus mostly on
those under the System and the Kernel subheadings. It's generally safe to
ignore media framework and closed component issues (e.g. Qualcomm Closed-Source
Components).
If it has a link to a commit in Google’s tree, you can use that to search for
the code in debian code search.
If it doesn’t have a link to the commit, you can try a web or github search on
the CVE or the unique android ID (without the preceding A-). You may want to
skip CVEs without details earlier in the week and push it until Thursday/Friday
when it may have more details and handle it then.


Adding
------
1. after 'a'dding, either hit enter to accept the source package(s) suggested
by process_cves as those affected by the CVE or override the prompt by listing
all affected source packages at the prompt. This will open the generated CVE
file in an editor.

1. Set the Priority, if you can at this time. Should be one of 'negligible',
'low', 'medium', 'high' or 'critical'. You can also override the Priority
field on a per package basis, by using 'Priority_<source package>: ...'. If
some packages are marked DNE, you may wish to run `apt-get changelog` and check
for any name changes which process_cves didn't catch.

2. for each release, assign a status of (after the release_<source-package>
line): 'DNE', 'ignored', 'not-affected', 'needs-triage', 'needed', 'active',
'deferred', 'pending', 'released'

3. fill in any extra fields as needed (eg Notes, references to patches,
Assigned-to, Discovered-by, etc). Notes should be formatted as a nick,
separator and then a message. The separator is either '>' or '|':

 - '>' specifies to retain each line as listed in the CVE file as
   a separate line in the generated HTML

 - '|' specifies that lines should be appended to one-another in
   the generated HTML.

In either case, following lines can be indented by an extra space
so that the nick name can be omitted. For example the following two
Notes entries will be formatted the same in the generated HTML as
two separate lines:

 user> this is a message that spans multiple lines
  and continues onto a second line

 user> this is a message that spans multiple lines
 user> and continues onto a second line

Whilst the following two entries would both result in a single line of text
in the generated HTML:

 user| this is a message that spans multiple lines
  and continues onto a second line

 user| this is a message that spans multiple lines
 user| and continues onto a second line


If there are patches available, then use:

Patches_PKG:
 debdiff: URL
 vendor: URL
 upstream: URL
 other: URL

Eg, for source package 'foo' that has a debdiff in launchpad, use:

Patches_foo:
 debdiff: https://bugs.launchpad.net/ubuntu/+source/foo/+bug/XXXXXX

If a CVE only affects a binary in universe (from a source in main),
this can be marked using a Tag field. E.g:

Tags_foo: universe-binary

A package may not be supported by the Ubuntu Security team, but might be by
another Canonical team (eg linux-armadaxp is in main, but not officially
supported by the security team). This can be marked like so:
Tags_foo: not-ue

If a package has been protected by some sort of pro-active security measures,
mark from the list of "apparmor", "stack-protector", "fortify-source",
"symlink-restriction", "hardlink-restriction", "heap-protector", "pie" etc:

Tags_bar: stack-protector
Tags_baz_trusty: stack-protector

Use the above tags if the protection will be mentioned in the USN and/or the
protection mechanism is shown to protect against the vulnerability. Also note
that the tag is per release only, so you must say each release that is
protected (ie, in the above example, baz on trusty is protected, but not
lucid or precise). Valid tags are in 'valid_tags' in cve_lib.py.

When populating the Discovered-by field, keep in mind that the patch submitter
is not always the discoverer. If there is a nick, you can credit them but try
to track down a real name for the USN. Company names are not in the field.

4. Check Debian's secure-testing data/embedded-code-copies to see if any
other software is to be included in this CVE


Ignoring
--------
Be sure list why and what piece of software it is. Eg:
 Unpackaged software (Does Not Exist): 'DNE - PhpNuke'
 Totally alien stuff (Not For Us):     'NFU - Cisco IOS'

CVEs that affect Ubuntu releases can also be ignored. This is most often done
for packages that exist in a previous release, but that release has reached End
of Life. Eg:

upstream_foo: released (1.2.3)
lucid_foo: ignored (reached end-of-life)
precise_foo: released (1.2.2-1ubuntu1.2)
trusty_foo: not-affected (1.2.3-1)
utopic_foo: not-affected (1.3.0-1)
devel_foo: DNE



Ubuntu Priorities
-----------------
These are very similar to the Debian priorities, but with some differences.
Priorities can be roughly mapped as:

  negligible	Something that is technically a security problem, but is
		only theoretical in nature, requires a very special
		situation, has almost no install base, or does no real
		damage.  These tend not to get backport from upstreams,
		and will likely not be included in security updates unless
		there is an easy fix and some other issue causes an update.

  low		Something that is a security problem, but is hard to
		exploit due to environment, requires a user-assisted
		attack, a small install base, or does very little damage.
		These tend to be included in security updates only when
		higher priority issues require an update, or if many
		low priority issues have built up.

  medium	Something is a real security problem, and is exploitable
		for many people.  Includes network daemon denial of service 
		attacks, cross-site scripting, and gaining user privileges.
		Updates should be made soon for this priority of issue.

  high		A real problem, exploitable for many people in a default
		installation.  Includes serious remote denial of services,
		local root privilege escalations, or data loss.

  critical	A world-burning problem, exploitable for nearly all people
		in a default installation of Ubuntu.  Includes remote root
                privilege escalations, or massive data loss.


Package Status
--------------
For a given CVE, the package and release with status is encoded as:

 <release>_<source-package>: <status> (<version/notes>)

  DNE		The package (for the given release) does not exist in the
		archive.

  needs-triage	The vulnerability of this package (for the given release)
		is not known.  It needs to be evaluated.  (No version/notes)

  not-affected	This package (for the given release), while related to the
		CVE in some way, is not affected by the issue.  Notes
		should contain further information, if needed.  For example,
		if a given source package is vulnerable to a CVE, but the
		compiled binary is not (for example, linked to use a
		system copy instead of an internal-to-source copy of a
		library, and the CVE is about the internal copy).  For
		such a situation, the note should include the research
		about why the binary is not affected by the CVE. Another
		example is when an earlier or later version of the package was
		affected, but the current version is not.  If a package
		was fixed during a devel release by someone outside of the
		security team, it is appropriate to put the version that
		fixed the issue in the note.  If a note is too long,
		it can be moved to the top-level "Notes" section.  Examples
		of common notes used with not-affected:
			code not present
			linked against (poppler|system libraries|etc...)
			(MacOS X|Windows|Redhat) only
			not included in package
			register_globals not supported
			network listening disabled by default
			by design

  needed	This package (for the given release) is vulnerable to the
		CVE and needs fixing.  (Notes are valid.)

  active	The package (for the given release) is vulnerable to the
		CVE, needs fixing, and is actively being worked on by
		the person belonging to the IRC nick in the "Assigned-to"
		field.	(Notes are valid.)

  ignored	This package (for the given release), while related to the
		CVE in some way, is being ignored for some reason. This could
		be because the package is no longer supported, or the CVE
		has been withdrawn, or because fixing the issue would break
		other functionality.
		The reason for decision should be recorded in brackets, e.g.:
		ignored (out of standard support)
		ignored (fix would unavoidably negatively impact other 
			packages)
		ignored (vulnerabilty has been disputed by upstream 
			maintainers)
		The "notes" section may give more detail and external links.
		
  pending	This package (for the given release) is vulnerable, and
		an update is pending, usually waiting for upload or
		publication.  The "version" should be the version containing
		the fix.

  deferred	The package (for the given release) is vulnerable, the problem
		is understood, but has been deferred for some reason. The
		"notes" need to explain further. If a date was specified eg
		"deferred (2012-01-01)" the date indicates the date the CVE
		was put in the deferred state.

  released	The package (for the given release) was vulnerable, but
		an update has been uploaded and published.  The "version"
		should be the version where the fix first appeared. This
		status should also be used for when the 'devel' release is
		fixed due to Ubuntu contributed changes (not-affected should be
		used when a non-Ubuntu contributed sync from Debian fixes the
		issue).


CVSS
----
Use https://cvssjs.github.io/ to calculate a CVSS score for CVEs that
Canonical assigns for which there is no existing CVSS score. Use the
vectorString in the CVE.

Our CVE files contain a CVSS field like the following:

CVSS:
 nvd: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H [9.8 CRITICAL]
 ubuntu: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H [9.8 CRITICAL]

This field can record one or more CVSS from different sources with
their own vectors, scores and severities as shown above.

check-syntax script can parse this field, so be mindful of any syntax
warnings.

As last note, do not confuse CVSS severity with the Priority field, they
represent two different things. Please see Ubuntu Priorities above.

Community Supported Packages
----------------------------
To most accurately reflect reality in community supported packages in the
archive, the following guidelines should be used when triaging community
supported packages:

1. CVEs in community supported packages for EOL released should follow the EOL
for the release (ie desktop/universe is 18 months for non-LTS, 3 years for LTS,
5 years for server). If based on the above the release is EOL, then the status
of the CVE should be 'ignored (reached end-of-life). See 'End of Life' section
for more information. Eg:
upstream_foo: released (1.2.3)
lucid_foo: ignored (reached end-of-life)
...

2. Look carefully at MITRE versions. If it has a 'fixed in' or 'less than',
adjust 'upstream' field accordingly to use this. Mark later versions as
'not-affected' and earlier as 'needed. be careful and leave as 'needs-triage'
if status is not clear for multiple branches (ie 1.2 vs 1.4). The 'upstream'
field may contain multiple versions, eg 'upstream_foo: released (1.0.1, 1.2).

3. If Debian has a fix in its development releases (unstable or testing),
prefer upstream version to Debian version in 'upstream' field, except where it
is fixed in Debian in an earlier version than upstream or no info on upstream
version is available.


Retiring a CVE
--------------
When a CVE fix is released, run sync-from-usns.py which will  update the CVE
file in active/ and retire it if appropriate.


UBUNTU-CVE Commands
-------------------
Useful commands are (all are run from within the top-level directory):

Verify syntax of CVE-* files
./scripts/check-syntax

To commit, use this command:
./scripts/check-syntax && git commit

Full listing:
./scripts/ubuntu-table

Full listing, flagging packages in main:
./scripts/ubuntu-table --supported

Show all active CVEs for supported (main) packages:
./scripts/ubuntu-table --supported 2>/dev/null | grep SUPPORTED

Number of active CVEs that are in main:
./scripts/ubuntu-table --supported 2>/dev/null | grep SUPPORTED | wc -l

Show all active CVEs for partner packages:
./scripts/ubuntu-table --supported 2>/dev/null | grep PARTNER

Show all out-of-sync CVEs for the devel release:
./scripts/ubuntu-table --supported | grep 'out of sync' | awk '{if ($8 == "needed*" || $8 == "needs-triage*") { print $0 }}'

Show open CVEs for a particular source package:
./scripts/pkg_status pkgname1 pkgname2 ...
./scripts/pkg_status -f pkgname1 pkgname 2 ... (full listing)

Show CVE history for a particular source package:
./scripts/pkg_history pkgname1 pkgname2 ...
./scripts/pkg_history -f pkgname1 pkgname 2 ... (full listing)

Show CVEs with undefined priorities (ie untriaged):
./scripts/ubuntu-table --untriaged

Create/edit a new CVE (eg if don't want to wait for check-cves):
./scripts/active_edit -p package -c CVE-YYYY-XXXX

Create a new CVE that does not have a CVE identifier yet:
./scripts/active_edit -p package -c CVE-YYYY-NNN1
./scripts/active_edit -e -p package -c CVE-YYYY-NNN1

See the status of specific CVEs:
./scripts/cve_status CVE-2006-4519 CVE-2007-2949 CVE-2007-3741

See the status of specific CVEs without viewing the full entry:
./scripts/cve_status -s CVE-2006-4519 CVE-2007-2949 CVE-2007-3741

See all bugs with priority of medium or higher:
./scripts/ubuntu-table --supported | egrep -v '[[:space:]]+(untriaged|negligible|low)$'

See a listing of packages with number of CVEs attached to them, weighted by
CVE priority:
./scripts/cve_packages
./scripts/cve_packages -m       (just supported (main, restricted and partner))
./scripts/cve_packages -u       (just unsupported (universe and multiverse))
./scripts/cve_packages -t	(just totals)
./scripts/cve_packages -a	(with assignees)

See ordering of SUPPORTED packages that need updates:
./scripts/cve_packages -m | grep '^[0-9]' | sort -n
./scripts/cve_packages -m -S | grep '^[0-9]' | sort -n	(skip devel)
./scripts/report-date.py -S -m (skip devel)

See all CVE assignments:
./scripts/cve_packages --by-assignee

See CVE assignments by individual:
./scripts/cve_packages --by-assignee --assignee=...
./scripts/cve_packages -a --assignee=...

Pull ubuntu-security bugs from Launchpad marked as 'In Progress':
./scripts/pull-in-progress.py
./scripts/pull-in-progress.py -u (updates active CVEs with patch information)

See CVEs with patches:
./scripts/cve_patches
./scripts/cve_patches -s (only supported)

Show items needing to be retired:
./scripts/ubuntu-table > /dev/null
./scripts/cve_need_retire
./scripts/cve_need_retire -f (full listing)
./scripts/cve_need_retire -p (list path to CVE)

Retiring items:
git mv $(./scripts/cve_need_retire -p) ./retired/

Ignore open CVEs for a certain release:
./scripts/pkg_status webkit | cut -f1 -d' ' | xargs -I{} ./scripts/mass-cve-edit -p webkit -r trusty -s ignored -v 'reached end-of-life' {}

Mark CVEs as "released" from known USNs:
wget -N http://usn.ubuntu.com/usn-db/database.pickle

or use rsync if you have access:
rsync -v --progress -e ssh people:~ubuntu-security/public_html/usn/database.pickle ./database.pickle

or pull through bzip2:
curl -s http://usn.ubuntu.com/usn-db/database.pickle.bz2 | bzcat > ./database.pickle

./scripts/sync-from-usns.py database.pickle -u

Check syntax without regard to new (USN'd) packages:
CVE_ALLOW_NEWER_PKGS=1 ./scripts/check-syntax

Check for releases in devel that are higher than upstream fixed versions:
./scripts/sync-from-versions.py -u

Check for releases in 'precise' that are higher than upstream fixed versions
for chromium-browser:
./scripts/sync-from-versions.py -u -r precise -p chromium-browser

Refresh descriptions from Mitre:
./scripts/check-cves --refresh

Refresh descriptions and publication dates from NVD:
wget -N http://nvd.nist.gov/download/nvdcve-200{5,6,7,8}.xml
./scripts/check-cves --refresh nvdcve-200*.xml

Update state for a bunch of CVEs for a particular package and release:
./scripts/mass-cve-edit -p <package> -r <release> -v <version> -s <state> CVE...
Eg:
./scripts/mass-cve-edit -p seamonkey -r karmic -s released -v 1.1.17+nobinonly-0ubuntu1 CVE-2009-1841 CVE-2009-1838 CVE-2009-1836 CVE-2009-1835 CVE-2009-1392 CVE-2009-1832 CVE-2009-1833 CVE-2009-1311 CVE-2009-1307

. scripts/dot.uct-functions.sh
git commit -em "$(uct_process_cves_commit_message)"
Commit with a generated message containing the count of CVEs triaged and a list
of packages with new CVEs


Reports:
./scripts/report-todo
./scripts/report-todo -S		(don't include devel)
./scripts/report-todo-numbers
./scripts/report-todo-numbers -S 	(don't include devel)

./scripts/html-report
./scripts/html-report -S		(don't include devel)

./scripts/monthly-report

All CVEs fixed in USNs for 10.04, with priorities:
./scripts/report-updates.py --with-eol | grep lucid

Kernel Report Example:
./scripts/ubuntu-table -p linux -P linux -S | cut -c1-14,36-95


Embargoed Items
---------------
Embargoed items are supported in the following scripts in all the scripts
except sync-from-usns.py.  If no CVE has been assigned yet, an embargoed item
should be prefixed with 'EMB-', followed by any combination of alphanumerics
and dashes.  Eg:
EMB-xorg-2007-0001
EMB-foo

To include embargoed items simply create a symlink from 'embargoed' to
the directory holding embargoed items. ubuntu-cve-tracker will not
use 'embargoed' unless it is a symlink.


Subproject Items
----------------
We are currently extending subproject items support in scripts.

To include subprojects items simply create a symlink from 'subprojects'
to the directory holding subproject items. ubuntu-cve-tracker will not
use 'subprojects' unless it is a symlink.


Non-CVE Vulnerabilties
----------------------
If find a non-CVE assigned vulnerability, then:

1. report the bug to Debian
2. in ubuntu-cve, use 00boilterplate and create CVE-NEED-0001
3. if desired, email [email protected] and Cc [email protected] asking for a CVE
4. file a bug in LP (assign to security-team if main, motu-swat if universe

Doing '1' may be enough if its in universe and not high priority, as
it will eventually find its way back to Ubuntu.


Stable Release Actions
----------------------
When a stable release is published, the active CVEs need to be adjusted to
reflect the new stable release.  e.g. when trusty was published:
  perl -pi -e 's/^((#?)devel_(.*))/$2trusty_$3\n$1/g' active/{CVE-,00boilerplate}*
The script tools will need to be adjusted as well.  There is usually some
lag time between the new devel archive opening and the stable release
getting published.  This means that "devel" will disappear from ubuntu-table
briefly:
  scripts/cve_lib.py should have the new release timestamp (in UTC) added
    to 'stamp' in 'subprojects'.
  you can generate this by looking at the release column in /usr/share/distro-info/ubuntu.csv
  `$ release=hirsute; date --utc +%s -d $(grep $release /usr/share/distro-info/ubuntu.csv | cut -f 5 -d,)`
  for esm:
  `$ release=bionic; date --utc +%s -d $(grep $release /usr/share/distro-info/ubuntu.csv | cut -f 8 -d,)`

  scripts/cve_lib.py should have an empty 'devel_release'.

Move all active CVEs and boilerplates from "devel" to release state:
./scripts/release-cycle-released $RELEASE


Development Release Actions
---------------------------
Fill in releases and devel_release in ubuntu-cve-tools/scripts/cve_lib.py

Move all active CVEs and boilerplates from latest release to devel state:
./scripts/release-cycle-devel-opens $LATEST_STABLE_RELEASE

Add release to non-ports and ports section of
ubuntu-cve-tools/scripts/packages-mirror

End of Life
-----------
When a releases is end-of-lifed, all CVEs for that release must be updated.
Here is how:

1. add the release to the list of releases in 'eol_releases' in
   scripts/cve_lib.py

2. update the CVEs:
$ sed -i 's/^<release>_\(.*\): \(needed\|needs\-triage\)/<release>_\1: \2 (reached end-of-life)/g' ./active/CVE-*
$ sed -i '/^<release>_\(.*\): /d' ./active/00boilerplate*

3. retire the CVEs (see 'Retiring items', above)

This should generally be done as 1 commit with no other changes, for easier
review.


Ubuntu variants with PPA overlays
---------------------------------
Ubuntu Touch and Ubuntu Core use a ppa overlay on top of an Ubuntu base
release. cve_lib.py will list these as '<base>/<ppa name>' in all_releases
and subprojects. The <base>-<ppa name>-supported.txt files list the source
packages that comprise these variant releases. CVEs will use '<base>/<ppa
name>' as the release name for CVE tracking purposes.

Variants where the Ubuntu base release is EOL are possible, as with Ubuntu
Touch 15.04. In these instances, the base release is marked end of life while
the variant release is still active and updates will only be provided to the
variant release via its ppa overlay.

Currently used variant overlay PPAs:
 * Ubuntu Touch: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages
 * Ubuntu Core 15.04: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages

Images built from these PPAs employ batched OTA (over the air) updates. As
such, when a package is uploaded to the PPA (or the base release distro version
if before the EOL) it should be marked as 'pending (<version>)' and only after
the stable image (ie, the one users use) has the package should the CVE be
marked as 'released'.  The following will report CVEs in this pending state for
overlay PPAs:
$ ./scripts/cve-alert.sh ubuntu-core
$ ./scripts/cve-alert.sh ubuntu-touch

Once the stable images have been updated, use the mass-cve-edit tool to mark
the CVEs as 'released (<version>)'.


New Backport Kernel
-------------------
When a new backport kernel is added, update scripts/cve_lib.py's
kernel_srcs and description_overrides.

Then update the 00boilerplate.linux with its entry, add that entry to each
CVE with an entry for the LTS the kernel was added to, and update all the
statuses for the newly added kernel, based off the version it will be
branched from. For example, to add a new kernel backported from Vivid to
the Trusty LTS release, run the following command:

./scripts/add-backport-kernel -l trusty -b vivid

You must also add the new backport kernel to the end of the
$UQT/security-tools/kernel-abi-check script.

Devel Release Closed
--------------------
During the week between a new release and when devel opens, the pre-filled
CVE templates from ./scripts/process_cves will give devel_foo: DNE without
actually knowing if the package exists or not. Change DNE to the proper
value for what the new devel release will need once it is opened.

Devel Release Opens
-------------------
Changes to tools:
  scripts/cve_lib.py should have new release added to 'releases',
    'devel_release', and 'subprojects'.


Vim syntax highlighting/checking
--------------------------------
$UCT/scripts/cve.vim can perform rudimentary syntax checking for CVEs. To use:
$ mkdir -p ~/.vim/syntax
$ ln -s $UCT/scripts/cve.vim ~/.vim/syntax/cve.vim

Then add to ~/.vimrc something like:
autocmd BufNewFile,BufRead CVE-[0-9][0-9][0-9][0-9]-[0-9][0-9][0-9][0-9] set syntax=cve

You can also option turn it on within vim using:
:set syntax=cve

Pre-commit Syntax Checking
--------------------------
To perform pre-commit syntax checking on only the files that have been
modified in the git tree, the following hook can be used. If an error is
discovered, the check-syntax output will be printed and then you'll have the
opportunity to ignore the errors or to exit immediately. To preemptively
avoid running check-syntax, you can set UCT_IGNORE_CHECK_SYNTAX=1 in the
environment.

$ cd $UCT
$ make dev_setup

This will install a git pre-commit hook that will run $UCT/scripts/check-syntax
on your modified CVE files.

Package Notes
-------------
Packages that share a codebase or are rebranded share the same vulnerabilities.
Eg:

firefox-3.0 and xulrunner 1.9 share codebase
iceweasel = rebranded firefox

Mass-update kernel team "released" tags to use correct rc versions:

	sed -i -e 's/^\(upstream_linux.*: released (2\.6\...\)-\(rc.*)\)/\1~\2/g' active/CVE-*


Triage Frequency
----------------
It is important to run check-cves on a regular basis. A suggested schedule is:

Monday:    check-cves nvdcve-2*.xml ; check-cves --import-missing-debian
Wednesday: check-cves allitems.xml ; check-cves --refresh nvdcve-*.xml
Friday:    check-cves nvdcve-recent.xml

MITRE is the definitive CVE database, but NVD contains the same information,
updates their database more frequently and also lists the PublicDate. Using the
above schedule allows our database to stay up-to-date with the NVD, and ensure
that our descriptions are also up to date.  For CVEs where the PublicDate is
wrong, we can override the value using the "CRD" field instead.

Since we want to keep a record of what the PublicDate was when the
USN published, USN publication should include the addition of the
"PublicDateAtUSN" field, which duplicates PublicDate, in case it changes
later. When answering the question "When did a CVE go public?" the
scripts will use CRD over PublicDateAtUSN over PublicDate. Times should
include the timezone; UTC is preferred. If no time is specified during
coordination, 14:00:00 UTC is recommended.

Eg: PublicDateAtUSN: 2009-03-27 23:45:00 UTC

Individual CVEs not in the databases yet can also be added with
scripts/active_edit. Be sure to use the '--embargoed' flag when adding CVEs
that are not public yet (and double check that it wasn't accidentally added
to the public tracker).

If you setup mitre_loc and nvd_loc in ~/.ubuntu-cve-tracker.conf, then this
can all be taken care of for you with:
$ ./scripts/process_cves
$ ./scripts/process_cves [Mon|Wed|Fri]

Specifying anything other than Mon, Wed, or Fri simply runs check-cves on
nvdcve-recent.xml.

Example ~/.ubuntu-cve-tracker.conf setup for the security team:
mitre_loc="people.canonical.com:/home/ubuntu-security/cache"
nvd_loc="people.canonical.com:/home/ubuntu-security/cache"

Sometimes MITRE is behind in getting CVEs into the database. It is recommended
that http://www.openwall.com/lists/oss-security/ also be reviewed for new CVE
assignments for packages in main.


Status Transitions
------------------
For stable releases, "scripts/sync-from-usns.py" should flip statuses to
"released". "scripts/sync-from-versions.py" can also be used for stable
releases when specifying '-r <release>', which might be useful for things
that are in universe but get new upstream versions.

For the devel release, only "scripts/sync-from-versions.py" should flip
statuses to "released". (The "--stable-pending" option will break this rule
if you need it to.)

The version (status comment) on a "pending" or "released" is considered
canonical. The USN database, however, will show when a fix was first
published to the -security pocket, and may have a later version.

Notes about what to do with kernel bugs and the tracker:

UCT			  	LP
---                  	        ------------
bug			->	lp (and if it's a dup, update to master)

When description has "Placeholder" only (i.e. new bug):
DNE			->	(New) -> Invalid
not-affected		->	(New) -> Invalid
pending			->	(New) -> Fix Committed
released		->	(New) -> Fix Released
Patches:...upstream:	->	"Break-Fix: BROKEN_SHA FIXED_SHA" (multiple)

Once alive:
* phase 1:
DNE			->	Invalid
pending			->	(Invalid,New,Confirmed,Triaged,In Progress)->Fix Committed
released		->	Fix Released
not-affected		->	(New)->Invalid
ignored			->	(New)->Invalid
[priority]		->	Importance
deferred			skipped (ie no processing)
* phase 2:
needed			<-	Confirmed/Triaged/In Progress
needs-triage		<-	New
not-affected		<-	Invalid (double-check with DNE)
Patches:...upstream:	<-	"Add-Break-Fix: SHA SHA" (multiple)
Patches:...upstream:	<-	"Del-Break-Fix: SHA SHA" (multiple)
deferred			skipped (ie no processing)
* phase 3:
needs-triage		->	New
Description:		->	Description with shas...
Patches:...upstream:	->	"Break-Fix: BROKEN_SHA FIXED_SHA" (multiple)

Closed bug that needs a SHA change:
	- create new bug
	- dup old bug to new bug

TODO/THINK-ABOUT:
	- sha1 introduced CVE, sha1 fixes it (if one sha1, needs another)
	- "Patches_linux" new identifier "break-fix" with introduced/fixed-by shas
		- "introduced-by" can be either sha or rc1 tag ("v2.6.35-rc1") or "-" (infinity)