|
|
Steven M. Christey mentioned:
>Some Board members have said not to create CVE entries for vaguely
>reported issues. But should a vulnerability scanner tell a system
>administrator that they haven't installed a patch that has been
>specifically labeled as security-related, by the vendor?
>Vague advisories make things difficult for certain types of analysis -
>including CVE - but I suspect that many consumers of vulnerability
>information would rather have a CVE name for *some* vulnerability,
>rather than no CVE name at all. CVE would not directly run across
>vague advisories if our data sources didn't think it was important to
>report them.
The fact that a vulnerability scanner should have an entry for a vague problem assumes that the vagueness of the problem does not inhibit the vulnerability scanner from testing for it.
If the problem is remedied by a patch, the vulnerability scanner is only going to be aware of the unpatched version if 1) the scanner is a network scanner and the software package displays a banner with version info, or 2) if the vulnerability scanner is a local based host scanner.
Other than that, unless "vaguely vulnerable version A" handles protocols differently than "patched and supposedly not vulnerable version B", then there would be no way for the vulnerability scanner to even know of its existence. Therefore I would say that the ability to test for existence of the vague vulnerability should come under heavy scrutiny during the voting process for any specific CD:VAGUE, otherwise its merely a handle that refers to non-existence, a concept with no foundation other than the vendors reccomendation for upgrade.
-Jimmy Alderson
e-Security Inc.