[Secure-testing-team] Proposal: new tags

Florian Weimer fw at deneb.enyo.de
Tue Sep 13 22:01:16 UTC 2005


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 at debian.org> about this. 
	NOTE: Goran Weinholt <weinholt at 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.




More information about the Secure-testing-team mailing list