Re: PROPOSAL: Cluster 20 - DESIGN (27 candidates)
hmm ... let me follow up.
I like your 'rule of thumb', but it needs some refinement, IMHO.
Let's consider the '.forward' example. It's a feature that you might want
to use. Its behaviour is well-known. It's not, if I understand you
correctly, a vulnerability by itself. Though, it becomes a vulnerability if
I can create or modified one where you were not expecting to find one (e.g
well known attacks using ftp + .forward, or uucp+.forward, ..)
Is the '.forward' the vulnerability? At the contrary, should we have a CVE
entry for each 'misuse' of the '.forward'? Should we see this as a
misconfiguration problem for ftp, uucp ... What about .forward that are
left as backdoors by bad guys ...
sorry for opening the can of worms again but I couldn't resist .. :-)
PS: and we can keep going with almost every config file that, as a feature,
enables you to execute command before invoking the associated software (vi,
Gene Spafford <spaf@CS.PURDUE.EDU> on 07/21/99 05:44:36
Please respond to spaf@CS.PURDUE.EDU
To: "Steven M. Christey" <coley@LINUS.MITRE.ORG>
cc: email@example.com (bcc: Marc
Subject: Re: PROPOSAL: Cluster 20 - DESIGN (27 candidates)
Suppose we consider a "rule of thumb:"
Any software that functions according to its specification, and whose
correct functioning is within the bounds of a common security policy
(but not necessarily *every* policy) will NOT be considered a
vulnerability for inclusion in the CVE."
Thus, the finger program would not be a vulnerability so long as all
of its functions are correct and known. We might allow its use in
an academic environment, so it is not a vulnerability.
By that token, I would contend that guessable passwords are not a
Of course, this introduces the question of where do we get complete
specifications and common policies.... :-)