Re: [Secure-testing-team] Re: CVE-2005-2973: Yet another kernel DoS
On Mon, 2005-10-24 at 19:39 +0200, Florian Weimer wrote:
> * dann frazier:
>
> > Horms: I realize you might be somewhat out of the loop as to how we're
> > abusing your directory tree; I'll catch you on IRC when you're back to
> > explain in detail.
>
> Could you write a short statement to the mailing lists, please?
Sure - good idea.
Micah and I have created an evolving schema, using rfc822-style files.
Currently we're storing this data in
svn://svn.debian.org/svn/kernel/people/horms/patch_notes, though we
should probably move it elsewhere once we've settled on the
architecture.
I proposed the rfc822 layout because its familiar to Debian people, and
I have a small python library that I can use to read & write this
format.
The idea is we'd have one rfc822 file per patch, and include all
relevant information there - including CVE status, inclusion status
across currently maintained source trees, description information, etc.
If you look in Horms' cve directory today you'll see a lot of
CAN-XXXX-XXXX files - we're thinking about making this ID just a field
in the file named after the patch, so those may go away - ignore them
for now.
Currently, our file layout looks like this (slightly modified for
example's sake):
$ cat net-ipv6-udp_v6_get_port-loop.patch
======================================================
Candidate: CVE-2005-2973
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2973
Reference:
CONFIRM:http://linux.bkbits.net:8080/linux-2.6/cset@4342df67SNhRx_3FGhUrrU-FXLlQIA
Description:
Fix infinite loop in udp_v6_get_port().
Bug:
fixed-upstream: 2.6.14-rc4, 2.6.13.3
2.6.13: released (2.6.13+2.6.14-rc4-0experimental.1)
2.6.8-sarge-security: pending (2.6.8-16sarge2)
2.4.27-sarge-security: pending (2.4.27-10sarge2)
>From here you can gather that this is a security fix that went into
2.6.14-rc4. Its been released in our 2.6.13 source tree, starting in
version 2.6.13+2.6.14-rc4-0experimental.1.
> For example, I'd like to get a list of the 2.6.12.6 security bugs
> which have *not* been assigned CVE names. Which data sources shall I
> combine to obtain this information?
Eventually, and this is very subject to change - especially as we
haven't discussed this with Horms yet, you should be able to follow this
process:
Look in all files for a fixed-upstream field containing 2.6.12.6. In
those that match, look for a Candidate field with the string
"##NEEDED##".
I think the biggest problem your example will have with this data format
is that we aren't tracking patches by the upstream release they arrived
in. You'll have to count on either having your own list of patches that
came with 2.6.12.6 and mapping those to our patch names, or count on
someone being diligent enough to keep the fixed-upstream field up to
date.
--
dann frazier <dannf@dannf.org>
Reply to: