Re: Which "Codebases" do these candidates really split into?

[Gene Spafford <spaf@cs.purdue.edu>]

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

Systems that used the old BSD IP stack have this problem.   The Linux 
stack was developed independently, as was (I believe) AIX.   All of 
the others derived from the same underlying IP code.   However, each 
one has undergone quite a bit of change.

MacOS is also vulnerable in some versions.   I believe VMS and 
NextStep were too.

So here we have the problem of defining "same."

Me feeling would be to split out each independent OS unless we know 
they use the same underlying code.


>
>
>
>
>=================================
>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?

vi and ex are the same program.  It was written by Bill Joy, and is 
largely unchanged since the early 1980s.   Thus, it is the same 
codebase, and the same error is likely to occur on any system to 
which the code was ported (e.g., SCO, AIX, etc).

>
>
>
>=================================
>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?

rlogin is the codebase.  It was the same on almost all these systems.

The Linux and NetBSD versions were fixed before the advisory because 
they had groups doing proactive security screening.   It doesn't 
change that the code base for rlogin was basically the same.

>
>
>
>=================================
>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?


Wasn't Eudora vulnerable to this?

--spaf