Date: Wed, 09 Jul 2008 11:29:03 +0200 From: Matthias Andree <matthias.andree@....de> To: oss-security@...ts.openwall.com Subject: Re: Major DNS vulnerability announced [CVE Question] Steven M. Christey schrieb: > On Tue, 8 Jul 2008, security curmudgeon wrote: > >> Microsoft has: >> DNS Insufficient Socket Entropy Vulnerability - CVE-2008-1447 >> DNS Cache Poisoning Vulnerability - CVE-2008-1454 >> >> Cisco has: >> CVE-2008-1447 >> >> Question: Is CVE going to keep those two identifiers for the fundamental >> issues, and load them up with affected vendors? > > Based on my current read of things (perhaps faulty, and definitely without > all the relevant details), CVE-2008-1447 is for a fundamental design > problem with DNS itself, so it applies to all implementations (or "most," > according to CERT... I'm afraid to ask the followup question). > > CVE runs into this kind of challenge a couple times a year. Usually it's > for PROTOS-style analyses that find tons of issues in tons of > implementations, where there are so many complications (and often > insufficient details) that only a couple CVE's are used to identify them > all. However, when it comes to protocol design issues, it's not always > clear what to do. > > In this case, there's also the practical implication that the same CVE is > already being used for BIND, MS, and Cisco. So even if we realize that > splitting into separate ID's would be technically correct, doing so would > probably cause more headaches than it solves. (Although as Mark Cox > mentioned to me, CVSS scoring might be more problematic since we have > multiple products with the same CVE.) > > Unfortunately, these are limitations of CVE, especially early in the > disclosure process. Steven, what you describe looks like a problem how to assign figures - should the CVE name be assigned to a vulnerability (of a concept or something), or to a particular implementation? There are sometimes mitigating factors for certain implementations, such as distribution-specific compiler fortifications of the code, the pertinence of particular implementations or something. Would you want to assign individual CVE names? I doubt that, both from reading between your lines and from what I'd see as useful. IMO, a proliferation of CVE names for related vulnerabilities helps no-one. I think what may make sense is to have a vulnerability-specific CVE name as an umbrella (and you seem to be saying that this is the easier way to solve the issue), even if different implementations show different susceptibility - which might make a point for providing implementation-specific CVSS. The latter may still explode in our faces. So you might go: CVE-2008-1447 (1) Microsoft Windows $VERSION_SET(): CVSS vector foo=2/blah=4 (2) Bind $VERSION: CVSS vector foo=3/blah=3 (2) where (1) is the CVE "umbrella" and (2) are implementation-specific CVSS variations; but you probably don't want to go into more detailed variations like (I'm rolling dice for numbers here and am exaggerating) Bind VERSION 188.8.131.52.patch123 on Solaris 10 FCS Bind VERSION 184.108.40.206.patch654 on FreeBSD 7.0-STABLE checked out at full moon when run in a jail on IP 10.9.8.7 and the administrator's maternal grandpa passed away on a Wednesday I've personally always seen the CVE as a "chance of vulnerability"; how severe it is in MY installation is up to the implementation's vendor and my system administrator to decide (including misjudgments if $SOME_VENDOR wants to forfeit user trust, which isn't too prevalent in OSS) and often enough configuration dependent if the problematic code was in a certain branch of the code. If this concept is somehow viable, it should probably be refined and be based on an empirical study of problem cases that CVE has faced so far, and some more concept work. HTH -- Matthias Andree
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.