Differences between revisions 5 and 6
Revision 5 as of 2010-03-26 17:20:30
Size: 3642
Editor: LucianoBello
Comment: link to debian-security-announce list
Revision 6 as of 2010-08-02 15:31:21
Size: 3900
Editor: LucianoBello
Comment: Some upgrade about versioning.
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:

This criteria for versioning is not always followed in stable fixes. In some cases, the developer just use "1+''release''1" with out the dot or even "''release''1". Please keep the criteria used (incrementing the last figure) if its not the first upload.

This is about the details of security update package preparation. See DebianSecurity/AdvisoryCreation/DebDev for the business of actually fixing the code.

Preparing fixed packages

Patch the package. Use whatever patching scheme the package you're working on already used. If the maintainer didn't apply any patches apart from the debian/ subdir, just use the native package diff without adding any patch support to the build. If it used dpatch, cdbs, quilt, etc., stick with that.

Depending on how far from the upstream release the Debian release is, you may have to either rework the security fix, broaden it to cover more cases, or come up with an alternate approach. In most cases, the upstream fix (assuming there is one) will apply more or less cleanly.

Create a new package version based on the original version-release, appending ".1+release1 for the first security patch in that distribution, .1+release2 for the second, and so forth -- for example, from 1.23-4 when making a fix to etch, use 1.23-4.1+etch1. If a previous NMU had used 1.23-4.1, increment the NMU to .2, and so forth.

This criteria for versioning is not always followed in stable fixes. In some cases, the developer just use "1+release1" with out the dot or even "release1". Please keep the criteria used (incrementing the last figure) if its not the first upload.

The first upload (and only the first upload) of any given fixed package to the security build system should include the upstream source (e.g. dpkg-buildpackage -sa). Use madison or elmo to find out whether the source is already in the security build archive.

Do your build in the distro you intend to fix (stable pbuilder or similar); be wary of introducing unintended dependency changes.

Testing fixed packages

There are two major things to test -- first, that the fix you've applied completely addresses the vulnerability (i.e. the exploit no longer works), and that you haven't introduced regressions. Non-hostile sample exploits may already be available (via vendor-sec or elsewhere), or in some cases (XSS attacks, e.g.) the attack is easy to reproduce.

no-dsa as an stable proposed update

If the issue doesn't worth a DSA Advisory (please, check this with the security-team) you should prepare an upload for stable-proposed-updates. You should send an email to debian-release@lists.d.o with the debdiff and ask for upload permissions. Read more about uploads to the stable and oldstable distributions at Developer's Reference, 5.5.1.

Writing the Advisory

There's a fairly standard template for this -- use a fresh DSA from debian-security-announce as an example, but compare others to get a sense of what's typical. Things to include:

  • CVE IDs, separated by spaces
  • Debian BTS numbers
  • Vulnerability type -- "multiple" if multiple vectors are involved, or list the specific one
  • Problem type (exploitability) -- local, remote, or "local (remote)"; attacks whereby a malicious party trick the user into downloading a file and running the vulnerable app on it fall into the latter category.
  • Debian-specific: generally no, unless the vulnerability came about through a change made by the maintainer not found in upstream or standard versions

If updating a previous DSA, note what was wrong/missing about the previous one and how this update is different.

When CVE IDs exist for the vulnerability, list them, with a description of the nature of the flaw (buffer overflow, XSS, integer overflow, etc.) and the worst-known exploitability (DoS, privelege escalation, arbitrary code). Note what's possible; don't downplay or overstate the threat.

Give brief acknowledgment to the discoverer of the flaw, if they're known. If multiple people worked to assess the vulnerability, note them too.