I''d like to add a few additional tags.
REJECTED, RESERVED, NOT-FOR-US replace the corresponding "NOTE:"
variants. Parsing the old tags is rather fragile because NOTE: is
essentially a free-form field, so we often miss spelling errors. (The
old tags remain valid, though -- there is no need to replace them at
this point.)
"INVALID" means that the bug report is known to be false. For
example:
CVE-2003-0024
INVALID
NOTE: I have mailed Goran Weinholt <weinholt@debian.org> about this.
NOTE: Goran Weinholt <weinholt@debian.org> tell me that aterm 0.4.2 was
NOTE: never vulnerable to the problem described.
NOTE: this CVE is bogus.
"NOT-A-BUG" means that the bug report is factually correct, but we do
not view this as a vulnerability. Example:
CAN-2005-2541 (Tar 1.15.1 does not properly warn the user when extracting setuid
or ...)
NOT-A-BUG
NOTE: This is intended behaviour, after all tar is an archiving tool and you
NOTE: need to give -p as a command line flag
"IRREPRODUCIBILE" means that we have made reasonable effort to
reproduce the bug (mailing list research, rough source code audit, a
few exploit attempts), but we haven''t found any evidence that
it''s
actually there (or has been fixed in the past). For example:
CAN-2001-1429 (Buffer overflow in mcedit in Midnight Commander 4.5.1 allows
local ...)
IRREPRODUCIBILE
NOTE: I could track this down to this posting
NOTE: http://cert.uni-stuttgart.de/archive/vuln-dev/2001/11/msg00104.html
NOTE: This looks very obscure an does not contain useful information on how
this
NOTE: was triggered and even then it''s not a problem, as mcedit usage
does not
NOTE: have a remote impact and is not suid
By the way, none of these tags take any arguments (which conveniently
fits into the data model I''ve developed), and they are mutually
exclusive (as far as I can see). Entries with status NOT-FOR-US,
INVALID, NOT-A-BUG and IRREPRODUCIBILE may not mention any Debian
packages. (REJECTED and RESERVED do not carry this restriction,
because they mirror CVE status which isn''t under our control.)
Comments?
PS: I will add documentation for the Python scripts once things have
settled down a bit.
Joey Hess wrote:> Good idea on rejected and reserved. Not sure about not-for-us, part of > the resaon we put the name of the software in parens is to aid finding > bugs in software if it does end up entering Debian later on.I agree, leaving not-for-us is essential, we had a few issues that would have slipped through if we hadn''t had peer review through the svn-commits list.> > "INVALID" means that the bug report is known to be false. For > > example: > > > > CVE-2003-0024 > > INVALID > > NOTE: I have mailed Goran Weinholt <weinholt@debian.org> about this. > > NOTE: Goran Weinholt <weinholt@debian.org> tell me that aterm 0.4.2 was > > NOTE: never vulnerable to the problem described. > > NOTE: this CVE is bogus. > > Not sure how this is better than just the NOTEs by themselves.I don''t think this is needed. We can turn cases like these into REJECTED entries through our Mitre contact. Florian, did you find many cases like this?> > "IRREPRODUCIBILE" means that we have made reasonable effort to > > reproduce the bug (mailing list research, rough source code audit, a > > few exploit attempts), but we haven''t found any evidence that it''s > > actually there (or has been fixed in the past). For example: > > > > CAN-2001-1429 (Buffer overflow in mcedit in Midnight Commander 4.5.1 allows local ...) > > IRREPRODUCIBILE > > NOTE: I could track this down to this posting > > NOTE: http://cert.uni-stuttgart.de/archive/vuln-dev/2001/11/msg00104.html > > NOTE: This looks very obscure an does not contain useful information on how this > > NOTE: was triggered and even then it''s not a problem, as mcedit usage does not > > NOTE: have a remote impact and is not suid > > What''s the value in having this be machine parseable?We could just as well mark it "not-affected". If we can''t reproduce it and the maintainer agrees it most obviously won''t affect Debian. Besides, I think the main issue in this specific case is that it''s not a vulnerability. So simply add it to not-affected as well and consider it an issue only for distributions that ship mcedit suid (i.e. none). Cheers, Moritz
Florian Weimer wrote:> REJECTED, RESERVED, NOT-FOR-US replace the corresponding "NOTE:" > variants. Parsing the old tags is rather fragile because NOTE: is > essentially a free-form field, so we often miss spelling errors. (The > old tags remain valid, though -- there is no need to replace them at > this point.)Good idea on rejected and reserved. Not sure about not-for-us, part of the resaon we put the name of the software in parens is to aid finding bugs in software if it does end up entering Debian later on. This information can be hard to get from CAN descriptions otherwise. Also to record what software name we checked for in Debian, in case it turns out we didn''t look for the right thing or something like that. So I think it''s worthwhile to continue including that information in not-for-us.> "INVALID" means that the bug report is known to be false. For > example: > > CVE-2003-0024 > INVALID > NOTE: I have mailed Goran Weinholt <weinholt@debian.org> about this. > NOTE: Goran Weinholt <weinholt@debian.org> tell me that aterm 0.4.2 was > NOTE: never vulnerable to the problem described. > NOTE: this CVE is bogus.Not sure how this is better than just the NOTEs by themselves.> "NOT-A-BUG" means that the bug report is factually correct, but we do > not view this as a vulnerability. Example: > > CAN-2005-2541 (Tar 1.15.1 does not properly warn the user when extracting setuid or ...) > NOT-A-BUG > NOTE: This is intended behaviour, after all tar is an archiving tool and you > NOTE: need to give -p as a command line flagThis is already handled by the "unimportant" severity, which also lets us cross-reference to the bug report in case we want to revisit it later.> "IRREPRODUCIBILE" means that we have made reasonable effort to > reproduce the bug (mailing list research, rough source code audit, a > few exploit attempts), but we haven''t found any evidence that it''s > actually there (or has been fixed in the past). For example: > > CAN-2001-1429 (Buffer overflow in mcedit in Midnight Commander 4.5.1 allows local ...) > IRREPRODUCIBILE > NOTE: I could track this down to this posting > NOTE: http://cert.uni-stuttgart.de/archive/vuln-dev/2001/11/msg00104.html > NOTE: This looks very obscure an does not contain useful information on how this > NOTE: was triggered and even then it''s not a problem, as mcedit usage does not > NOTE: have a remote impact and is not suidWhat''s the value in having this be machine parseable? -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050914/123e54b0/attachment.pgp
* Joey Hess:> Florian Weimer wrote: >> REJECTED, RESERVED, NOT-FOR-US replace the corresponding "NOTE:" >> variants. Parsing the old tags is rather fragile because NOTE: is >> essentially a free-form field, so we often miss spelling errors. (The >> old tags remain valid, though -- there is no need to replace them at >> this point.) > > Good idea on rejected and reserved.Okay, I''ll implement something like this.> Not sure about not-for-us, part of the resaon we put the name of the > software in parens is to aid finding bugs in software if it does end > up entering Debian later on.Let''s use "NOT-FOR-US: reason" then. I want to get rid of "NOTE: not-for-us" because it''s quite hard to detect misspelled variants. It doesn''t matter much at the moment because the field isn''t parsed mechanically.> This information can be hard to get from CAN descriptions otherwise.I think the iCAT database offers normalized product names and CVE cross-references.> Also to record what software name we checked for in Debian, in case > it turns out we didn''t look for the right thing or something like > that. So I think it''s worthwhile to continue including that > information in not-for-us.Agreed.>> "INVALID" means that the bug report is known to be false. For >> example: >> >> CVE-2003-0024 >> INVALID >> NOTE: I have mailed Goran Weinholt <weinholt@debian.org> about this. >> NOTE: Goran Weinholt <weinholt@debian.org> tell me that aterm 0.4.2 was >> NOTE: never vulnerable to the problem described. >> NOTE: this CVE is bogus. > > Not sure how this is better than just the NOTEs by themselves.I used to treat bugs without explicit resolution as to-do items. But you are right, this is only necessary when bootstrapping annotations. You currently handle this by automatically adding TODO, I think. I could do something similar if I really want to go ahead and gain some insight into sarge''s security status.> What''s the value in having this be machine parseable?We could generate a list of such issues. But it''s more like QA for CVE, and not really related to our task.
* Moritz Muehlenhoff:> I don''t think this is needed. We can turn cases like these into > REJECTED entries through our Mitre contact. Florian, did you find > many cases like this?See my message to Joey. I mainly want to do this to have a clean resolution for each CVE entry (explicit package list, or a reason why there isn''t one).> Besides, I think the main issue in this specific case is that it''s not a > vulnerability. So simply add it to not-affected as well and consider it an > issue only for distributions that ship mcedit suid (i.e. none).I think such bugs, if reproducible, are still security issues. Maybe nobody uses mcedit as a pager or from mutt, but users have a reasonable expectation that opening a file in an ordinary text editor does not automatically execute code contained in that file.