CONTENT DECISION: Different Program, Same Code

["Steven M. Christey" <coley@linus.mitre.org>]

In a single candidate, Mike Prosser managed to touch on two different
CVE content decisions :-)

>- ------------------------------------------
>Candidate: CAN-1999-0358
>Proposer: 001
>Assigned: 19990617
>Announced: 19990617
>Category: SF
>Reference: BUGTRAQ:Jan29,1999
>Reference: COMPAQ:SSRT0583U
>
>Digital Unix 4.0 has a buffer overflow in the inc program of the mh
>package.
>
>Modify:  Ref'd SSRT has an 'at' vulnerable as well supposedly fixed by
>the patch.  Shouldn't this be included as a seperate CVE in this
>cluster. ref:BugTraq "Digital Unix Buffer Overflows: Exploits" from
>Lamont Granquist for both as well.

In this case, I believe we should distinguish between 'at' and 'inc'
since they are functionally different.  They might have the exact same
line of code that's the problem - say, due to a programmer reusing
code, or it's a classic mistake - but they are fundamentally different
binaries.  Therefore I make this distinction in what I'm creatively
calling the Different Program, Same Code content decision (I wish I'd
labeled these in the original paper I sent to everyone in April ;-)

Do you agree with this approach?  Those who advocate the Same Codebase
decision - is *this* just another example of "same codebase"?  Or are
we all basically agreed that a distinction should be made between
programs with fundamentally different functionality?

To round out the picture...  Suppose a number of different binaries
(same OS, etc.) all use the same library, and a vulnerability is
discovered in the library itself.  Is that 1 vulnerability, or
multiple?  To me, it's 1 - i.e. "Same Program Same Code" - because
that particular vulnerability is occurring in the same function, the
same line of code.

- Steve