[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.64.1011151456250.2809@faron.mitre.org>
Date: Mon, 15 Nov 2010 15:02:21 -0500 (EST)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: oss-security@...ts.openwall.com
Subject: Re: econet iovec
On Sun, 14 Nov 2010, Dan Rosenberg wrote:
> This also raises a question of whether it's worth assigning CVEs to
> every vulnerability that was fixed by a single change in the core code.
> I'm leaning towards "no".
This is a big can of worms CVE-wise, since there can be multiple ways to
fix a single issue. As a result, I've come to believe that you shouldn't
try to define a vulnerability exclusively in terms of its fix. In
practice within CVE, if a single fix addresses an already-public CVE-xyz
and a whole bunch of other things, then we (generally) keep the
already-public CVE as is, and assign a new CVE(s) to the "bunch of other
things" that are simultaneously addressed.
For example - in package XYZ, you might have both XSS and SQL injection,
where the XSS is fixed by input validation (say, by ensuring that a
numeric input is actually converted to a number). This fix will
inadvertently address SQL injection, but a different XSS fix - say, proper
encoding - would not.
This is one of those areas where we can't be completely consistent in CVE,
and the amount of available information directly affects how many CVEs get
assigned.
- 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.
