Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Jul 2008 18:43:16 -0400 (EDT)
From: "Steven M. Christey" <>
Subject: Re: Major DNS vulnerability announced  [CVE Question]

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.

By the way, I'm treating Microsoft's "DNS Cache Poisoning Vulnerability"
(CVE-2008-1454) as something that's Microsoft-specific, pending any
further public details.  The bulletin doesn't seem to say anything about
it being a general design problem.

- Steve

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.