Re: PROPOSAL: Cluster 20 - DESIGN (27 candidates)

[dac@zurich.ibm.com]

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 .. :-)

Marc

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,
emacs, ...)





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:   cve-editorial-board-list@lists.mitre.org (bcc: Marc
      Dacier/Zurich/IBM)

Subject:  Re: PROPOSAL: Cluster 20 - DESIGN (27 candidates)




Hmm, interesting.

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
vulnerability, either.

Of course, this introduces the question of where do we get complete
specifications and common policies.... :-)

--spaf