CONTENT DECISION: Same Time of Discovery

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

[Note that I am slowly but surely trying to standardize Subject
lines.]


While reviewing the VEN-other cluster, Mike Prosser said:

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

Somehow the Digital 'at' didn't make it into the original 650.  This
is a gap that we will need to address in the future, as we begin to
fill in other gaps.

This particular example touches on a separate content decision that
relates somewhat to what we've been discussing.

Regardless of whether we adopt the Same Attack or Same Codebase level
of abstraction for the CVE, these Digital vulnerabilities are an
example of a "Same Time of Discovery" distinction I make between, say,
Digital's inc/at and the other inc/at commands that were found to be
vulnerable in other OSes a long time before it was observed in Digital
Unix.  (Reference CAN-1999-0033, which is still active within the CERT
cluster because of a RECAST by Andre Frech that's related to the
Attack/Codebase content decision.)

These vulnerabilities, as I believe Granquist pointed out, only arose
in their latest version of Unix because of their move to stack-based
execution (sorry if I've misstated that, but hopefully you know what I
mean ;-)

Assume for a second that we use the Same Attack level of abstraction.
That content decision might require that we include the Digital 'at'
with the other 'at' programs that were affected, e.g. Sun, AIX, and
others that Andre pointed out.

In this particular case, the Digital 'at' vulnerability didn't exist
at the same time as the others.  I believe that this is an important
distinction to make.  From the tool perspective, new checks need to be
developed (or at least, the old checks enhanced).  Everybody has to
"update" their vulnerability database to reflect this new fact, long
after the record had originally "stabilized."

Therefore I think such vulnerabilities need to be distinguished within
the CVE.  One could say that this makes sense because the
vulnerability didn't exist at the same time, and that would argue for
making a "same time of existence" distinction.

But let's generalize this to other (possibly theoretical) cases.  What
if the "new" vulnerability *existed* at the same time as the "same"
vulnerabilities, only nobody knew it at the time?  I think it should
*still* be distinguished, given that enough time has elapsed.
Therefore I've generalized the "same time of existence" into the Same
Time of Discovery content decision.

Comments?  Opinions?  What does "same time" really mean anyway, given
that it can take weeks or months to discover "all" affected
applications/OSes for the "same" vulnerability?

- Steve