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

["Prosser, Mike" <mike.prosser@L-3SECURITY.COM>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I agree with Pascal,
This is sort of along the lines of "same attack/same vulnerability"
and it fits well in that category (if you round the edges off a bit
and use a big hammer).  If we split the CVEs too much, we wind up with
multiple CVEs relating to a singularly known vulnerablity, as in
Pascal's Ping O'Death example.  There aren't multiple Ping O'Deaths
vulnerabilities, there is one affecting multiple components (os,
firmware, etc).  Now , it may affect each of them slightly differently
depending on the codebase, but the overall affect is a Denial of
Service.
I realize that the decision was made to use the "same codebase/same
vulnerability" method in assigning CVEs but it doesn't always make the
most sense in every instance.  My opinion!

- -mike
- -----Original Message-----
From: Pascal Meunier [mailto:pascalm@CUP.HP.COM]
Sent: Sunday, July 18, 1999 6:41 PM
To: cve-editorial-board-list@lists.mitre.org
Subject: Re: Which "Codebases" do these candidates really split into?


This discussion is exactly what I was afraid of when we were
discussing
codebases, and I think it will happen again and again.  Codebases are
abstract, ambiguous notions, and the result could be an ambiguous CVE.

Let me throw something in the air and see if it will fly.  We have
been
thinking along the lines of "one CVE entry = one vulnerability".
However,
could we represent more than one vulnerability instance by a CVE
entry?  We
already have done so with the password CVE entries (Cluster 18 -
PASS).  I
think of those as "Exploding" CVE entries.  That is, think of each CVE
entry as a compact notation for unambiguously signifying the existence
of
several vulnerabilities, specified with a list of *different
instances* of
the same problem.  Could we not use this over all the database?  It
may be
understood that each OS, distribution (with version numbers, please!)
has a
different vulnerability that fits the observables in the description.

Hence, the  Ping o' Death entry could look like:
Candidate: CAN-1999-0128
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.

Instances:
- -Digital Unix 3.0x, 3.2x, 4.0, 4.0a and products based on these
- -FreeBSD v prior to 2.1.6
- -HPUX 9.x, 10.00-10.20,
- -AIX 3.2, 4.1, 4.2
- -Linux kernels prior to 2.0.27
- -OSF/1 prior to R1.3.3
- -SCO OpenServer 5.0.0, 5.0.2
	SCO Internet FastStart 1.0.0, 1.1.0
	SCO Open Desktop 3.0
	SCO TCP/IP 1.2.1 on SCO Unix System V/386 Release 3.2 Version 4.2
- -Solaris, unpatched versions prior to 5.51

I think it would be a waste of bits to have a dozen different CVE
entries
for this, while the sub-enumeration unambiguously specifies that the
underlying code may be different.
Pascal


>On Mon, Jul 12, 1999 at 09:52:28PM -0500, Gene Spafford wrote:
>
>| >Candidate: CAN-1999-0128
>| >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.
>
>It seems clear to me that the relevant logic that leads to the system
>crashing while processing ICMP have not changed.  My definition of
>codebase change and Spaf's seem to be different.
>
>We agree on expresserve, which I've elided, and disagree on rlogin:
>
>| >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.
>
>Here is the core of our disagreement.  That linux and NetBSD code was
>audited and changed to prevent the bug from working is the essense of
>a codebase change thats relevant to the CVE.  Code changes that don't
>affect the vulnerability don't matter, because from the CVE
viewpoint,
>they're not code changes.
>
>Adam

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQA/AwUBN5NMwRIUaHPadf5hEQLddACeM8ATPsvPFwUWyWdHu5zzf0LZvIkAmwcQ
pL2L8VQ4a3k0S1qn4AMRXWnL
=sP5y
-----END PGP SIGNATURE-----