[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposed guidelines and procedure for "Team to patch vulnerabilities"

As promissed in
I've written a rough plan...

Bugs get filed using appropriate procedure then... The "team to patch
vulnerabilities" finds the bugs and starts its procedure... I still need
to work on the procedure, and I'm thinking up a better name for the team.
Perhaps "Debian Vulnerability Patch Team" or alike... I imagine most
people on this team won't be Debian Developers or else they'd be on the
Debian Security Team so some effort in naming is needed not to overlap or
take away from their efforts...

It occures to me that many may be interested in joining this "team" just
for ego, resume fodder, 1337ness... To make sure this doesn't interfere
with anything I won't be putting together a roster. If I do give credit it
will based upon information available to me such as valuable contributions
to the BTS, the Security Team, maintainer(s) and/or mailing lists. I don't
keep any metrics on how much I've helped out and I regard this as time
consuming and perhaps a waste of time. I don't expect to do it for others,
but it'd be nice if someone did it for me. I also don't think it would
hurt for people to keep track of their own contributions, and how helpful
they were... if you want me to acknowledge it you'll have to give
references to what you've done. I may also dispute various metrics... I
don't want to see time wasted on flames though (hopefully not flames by
me, I don't intend to flame, and I don't like flame-bate).

Some guidelines:
New security bugs should follow proper procedure. Read
http://www.debian.org/security/faq and note that whenever a new security
bug is found send an e-mail to team@security.debian.org If it's public
knowledge or an extremely low risk and/or low hazard vulnerability then
maybe file a bug in the BTS and set "Tags: security"... Some co-ordination
between vendors and upstream(s) may be nessisary before vulnerabilities
should be made public. Be careful not to file bugs that are not in Debian
packages [1].

The BTS should be proprly used. Read through the documentation at
http://www.debian.org/Bugs/ Please use the Tags as much as possible
(security, potato, woody, sarge, sid, patch...). Please check if stable
(now woody) oldstable (now potato), unstable (aka sid) and Testing (now
sarge) could be affected. Don't assume that it is or isn't based upon its
version number alone [2].

Give maintainers and the security team time to fix bugs. The security
team's timeline *might* be directed by their policy(?) [3] to issue a DSA,
fix or not, within one week. Maintainers *may* be given "a few days" to
respond before people should bother writing a patch, and after a patch is
submitted it is recomended to "wait a few more days" for a responce [4].
After the wait is up talk to a Developer about doing an NMU [5] or do one
if you are a Debian Developer.

[1] Debian "stable" sometimes has security patches backported from newer
version numbers. Also there may be differences in the Debian version (that
should only be in the Debian diff file) and upstream (which should be the
same as the orig source). Security scanner false positives should be filed
if and when they occure (Eg, nessusd).

[2] In additon to [1], sometimes vulnerabilities are only introduced in
later versions. Check the differences in the source code if you can (it'll
need to be done eventualy), and try to exploit yourself if an exploit is

[3] http://lists.debian.org/debian-devel/1999/debian-devel-199908/msg01933.html

[4] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu-when

[5] Acording to
debian-mentors@lists.debian.org might be the best place to request an NMU,
but for example, an apache NMU request might go to debian-apache. Another
good example is requesting an NMU of a package like libdb in debian-perl
as a libdb RC bug affects perl. Note NMU's usualy don't get seen for at
least 7 days after uploaded. Is there a way for non-dd (non Debian
Developers) to check incomming/delayed?

Some Resources:
http://qa.debian.org/bts-security.html lists bugs in the BTS that are
tagged security.
The Debian archive (it's a bit confusing to me still). It has source for
all distributions that have the package (except maybe some non-free). Note
that potato didn't use the pool directory structure.
http://www.steve.org.uk/Debian/ is one example of a security audit that
this team might help support

3rd party security information sources:
http://www.securityfocus.org especialy under BIDs
http://packetstormsecurity.nl and it's many mirrors
CERT, other advisory places (like mitre or iss), vendors like Mandrake,
SUSE, RedHat...

For human help with patches:
Upstream (see the copyright and files in the source, other bugs, a search
team@security.debian.org (they're overworked so don't push them)
debian-security@lists.debian.org and its archives at
Debian mentors at debian-mentors@lists.debian.org and its archives at

Proposed procedure:

First find a bug in the BTS (I'm trying to work on a way to priortize them
better) then...
Post information about your research frequently, but don't be annoying
(eg, don't file minute by minute reports). Let people know what work you
are doing to avoid duplication. Don't forget to cc people/lists/bugs when
1- Verify that the bug exists (either by good code reading or testing).
2- Check for existing patches and workarounds or even complete new
versions that fix the bug.
3- If upstream hasn't acknowledged the bug or been informed, let them know
about the bug.

Note: patches can be avoided if only unstable is affected and theres a new
version that fixes the bug.
4- Check if exsisting patches fix the vulnerability (preferably by
testing, but maybe by good code reading)
5- If a patch doesn't exsist, you *could* wait "a few days" (starting from
the initial bug filing or first public release of relevant information).
6- If a patch doesn't exsist, and no relevent (eg maintainer) responce is
given write a patch (Maybe with help from other sources or by other
7- Don't forget to post patches to the BTS and set the Patch tag.

8- Check if other distributions are affected (sometimes maintainers
accidentaly close security bugs that they fix in unstable when the bug is
still in other distributions). Following steps 1, 2, 4, 6 and 7. Please
set tags (potato, woody, sarge, sid) appropriatly if you notice only
certain distributions are affected.

9- If it has been more than 10 days (since the initial public releace of
relevant information), and the bug is in stable or oldstable, and it seems
no fix to the security bug is pending ask the Security Team (
team@security.debian.org ) for a responce (don't demand one, and don't
demand a DSA). Note: I would consider old bugs (more than a month old?) to
be acknowledged by the Security Team as they do occationaly read through
the BTS. Please respect the tags pending, and fixed. It's ok to question
wontfix and closure of security bugs, but be nice about it. If there's
still objections, ask the security team and/or
debian-devel@lists.debian.org for input. Note that sometimes a fix is
pending but the information isn't in the BTS or isn't in there properly,
please be nice about that.
10- If it has been more than 14 days and you feel an NMU is appropriate,
make your case and ask for one in the appropriate forum (or to an
individual). debian-mentors@lists.debian.org, security@debian.org
(developers private security list), debian-security@lists.debian.org and
debian-devel@lists.debian.org are examples of generic forums that may be
appropriate. Please follow the mailing list guidlines when sending
messages to them.

... find anaother bug.
Note: You don't have to do all the work. Please don't disregard the work
of others. Please don't be demanding of others. Please be polite. Thank
you. ;-)
I'm looking at a better way to priorize bugs. Perhaps similar to CVE's or
BIDS do by saying remote, buffer overflow... but I'd also like to include
visability and what's available/being used in the wild. I'd apreaciate
some help with this as it's not clear right now to me what a good method
is, and I'd rather be patching.

I'd also like to have regular updates taking about the status of security
bugs in Debian... A team status report if you would. I guess I've
volunteered to do this... I won't likely do much in the way of metrics
saying how much help was given, what kind of help, what kinds of problems
were created although that'd be nice. I really think it's important to
have some metrics for known open security bugs though. I'd like it if
someone else stepped forward and created such a status, again as I'd
rather fix bugs.

     Drew Daniels
PS: I've only mulled over this for an afternoon and have done no spell
checking. I didn't bug security@debian.org or the security team to comment
on this either, which I hope is less bothersome than telling them
implicetly and/or asking them directly for comment(s). I'm not a Debian
Developer and am not speaking on the behalf of anyone but myself.

Reply to: