Which "Codebases" do these candidates really split into?

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

All:

Now that the Editorial Board has adopted the Same Codebase content
decision, we now need to determine ways of deciding what really
constitutes the same codebase.

Below are a few of the candidates whose modification or acceptance had
been delayed until the Same Attack/Same Codebase content decision was
decided.  I will need to SPLIT them in the Modification phase.  So how
do we distinguish between their respective codebases?  Unfortunately,
I do not know Unix history well enough to be able to make such a
distinction to propose a useful SPLIT :-(

Note that most of these candidates are represented at the Same Attack
level in all databases that I've mapped to the CVE, including some
databases which have explicitly used the Same Codebase content
decision.

I have recorded the "affected operating systems or applications"
according to the CERT advisory, and some opening questions to help the
Editorial Board decide on each of these entries.

Once we have discussed how to determine the "Same Codebase" for these
examples, I will present some other affected candidates to see if our
discussions can apply to them as well.  Hopefully we can derive some
guidelines to assist a CNA who proposes this type of candidate(s).

- Steve



=================================
Candidate: CAN-1999-0128
Published:
Final-Decision:
Interim-Decision:
Modified: 19990621-01
Announced: 19990607
Assigned: 19990607
Category: SF
Reference: XF:ping-death
Reference: CERT:CA-96.26.ping

Oversized ICMP ping packets can result in a denial of service,
aka Ping o' Death.


AFFECTED OSes:
 Digital Unix, FreeBSD, HPUX, AIX, IRIX, Linux, OSF/1, SCO, Solaris

QUESTION: is the appropriate codebase "Unix"?  Or do we separate it
into BSD and System V?  Or each individual OS?




=================================
Candidate: CAN-1999-0132
Published:
Final-Decision:
Interim-Decision:
Modified: 19990621-01
Announced: 19990607
Assigned: 19990607
Category: SF
Reference: XF:expreserve
Reference: CERT:CA-96.19.expreserve

Expreserve, used in vi and ex, allows local users to overwrite
arbitrary files and gain root access.

AFFECTED OSes:
 HPUX, SunOS, Solaris

QUESTION: do we just separate HPUX from "Sun"?  Or do we separate
SunOS and Solaris since one's BSD-ish and the other's System V?
Delving into history, was vi originally some application that was
written by one person, which eventually was adopted into several OSes,
in which case perhaps we should consider these the Same Codebase?



=================================
Candidate: CAN-1999-0046
Published:
Final-Decision:
Interim-Decision:
Modified: 19990621-01
Announced: 19990607
Assigned: 19990607
Category: SF
Reference: CERT:CA-97.06.rlogin-term
Reference: XF:rlogin-termbo

Buffer overflow of rlogin program using TERM environmental variable


AFFECTED OSes:
  BSDI, Cray Unicos (maybe?), DG/UX, Digital, FreeBSD, HPUX, AIX,
  old Linux, NCR, old NetBSD, NeXT, OSF/1, SunOS, Solaris

QUESTIONS:
  With rlogin being an old program and so many Unices being affected,
  do we say this is just one codebase?  What does it tell us (if
  anything) to see that the problem had already been fixed in Linux
  and NetBSD before the CERT advisory was released?



=================================
Candidate: CAN-1999-0004
Published:
Final-Decision:
Interim-Decision:
Modified: 19990621-01
Announced: 19990607
Assigned: 19990607
Category: SF
Reference: CERT:CA-98.10.mime_buffer_overflows
Reference: XF:outlook-long-name
Reference: SUN:00175
Reference: MS:MS98-008

MIME buffer overflow in email clients, e.g. Solaris mailtool
and Outlook.

AFFECTED applications:
  Mutt, Pine, possibly SCO UnixWare, Sun mailtool, Netscape Communicator,
  Outlook/Outlook Express

QUESTIONS:
  This one looks pretty straightforward, a separate vulnerability
  for each application - unless the original MIME RFC's provided an
  example implementation that everybody used (Appendix D of RFC 1341
  at the very least has a boundary condition problem; RFC 1437 doesn't
  include any code, but it *was* released on April 1; later
  RFC's like 1523 and 1563 appear to be a little more conscious of
  potential overflows).  Are we missing any applications here?