[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Which "Codebases" do these candidates really split into?
-----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: firstname.lastname@example.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-----