Re: A new ambiguity
On Sun, 9 May 2010 16:40:27 -0400 Michael Gilbert wrote:
> On Sun, 09 May 2010 20:05:45 +0200 Florian Weimer wrote:
>
> > I have found what appears to be a previously unknown ambiguity in the
> > tracker input data. Consider these two DSAs:
> >
> > [01 May 2009] DSA-1785-1 wireshark - several vulnerabilities
> > {CVE-2009-1210 CVE-2009-1268 CVE-2009-1269}
> > [lenny] - wireshark 1.0.2-3+lenny5
> >
> > [29 Nov 2009] DSA-1942-1 wireshark - several vulnerabilities
> > {CVE-2009-1829 CVE-2009-1268 CVE-2009-2560 CVE-2009-2562 CVE-2009-3241 CVE-2009-3550 CVE-2009-3829}
> > [etch] - wireshark 0.99.4-5.etch.4
> > [lenny] - wireshark 1.0.2-3+lenny7
> >
> > data/DSA/list:977: warning: annotation on DSA-1785-1 overridden
> > data/DSA/list:363: warning: by annotation on DSA-1942-1 via CVE-2009-1268
> >
> > There are two possible interpretations:
> >
> > DSA-1785-1 was not issued for etch. CVE-2009-1268 is mentioned in
> > DSA-1942-1 because the fix for etch, and the fix lenny was already
> > in DSA-1785-1. Thus, "[lenny] - wireshark 1.0.2-3+lenny5" is the
> > correct annotation.
> >
> > The fix in DSA-1785-1 was incorrect, and it was corrected in
> > DSA-1942-1. Thus, "[lenny] - wireshark 1.0.2-3+lenny7" is the
> > correct annotation.
> >
> > Without more data, it is impossible to decide which interpretation is
> > the correct one.
> >
> > I'm open for suggestions how to add more information to the input data
> > to disambiguate this situation. One potential fix is to change {} to
> > apply only to the following package annotation, until the next {},
> > instead of merging all entries. With this convention, the DSA-1942-1
> > entry would look like this:
> >
> > [29 Nov 2009] DSA-1942-1 wireshark - several vulnerabilities
> > {CVE-2009-1829 CVE-2009-1268 CVE-2009-2560 CVE-2009-2562 CVE-2009-3241 CVE-2009-3550 CVE-2009-3829}
> > [etch] - wireshark 0.99.4-5.etch.4
> > {CVE-2009-1829 CVE-2009-2560 CVE-2009-2562 CVE-2009-3241 CVE-2009-3550 CVE-2009-3829}
> > [lenny] - wireshark 1.0.2-3+lenny7
> >
> > There is a certain amount of repetition involved. Another approach,
> > also involving repetition, would be to manually copy
> > "[etch] - wireshark 0.99.4-5.etch.4" into the CVE-2009-1268 entry in
> > data/CVE/list.
>
> this has actually come up every now and then, and we have just had to
> accept the wrongness. i was actually planning to implement the above
> solution at some point, but hadn't found the time. i don't think the
> additional repetition is too burdensome since the CVE info is (usually)
> automatically filled in by the dsa2list script.
btw, the root cause the problem is actually an ambiguity in the CVE
numbers listed in the security announcements.
the CVEs are parsed from this line in the security announcement:
CVE Id : CVE-2009-2625, CVE-2009-2626
which does not provide anyway to differentiate affected releases. a
solution would be to explicitly list the release names in that line:
CVE Id : CVE-2009-2625 (etch/lenny), CVE-2009-2626 (lenny)
this example unambiguously states that CVE-2009-2625 applies to both
releases and CVE-2009-2626 only applies to lenny.
mike
Reply to: