[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTim2JzZPkTbNMLSPVB0Ba1p+RXO0SETkqMah1e7h@mail.gmail.com>
Date: Mon, 15 Nov 2010 15:21:25 -0500
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: econet iovec
This makes sense to me. Just so everyone's on the same page:
CVE-2010-3859 (kernel heap overflow in TIPC) and CVE-2010-4160 (kernel
panic and potentially heap corruption in L2TP) are both fixed by
improved sanity checking on iovec input and new limits on network I/O
size.
The above mentioned issue in Econet (kernel panic due to integer
overflow in sk_buff allocation size on native Econet hardware) is no
longer an issue due to the previously mentioned fixes. This has not
received a CVE, nor do I necessarily think it needs one.
There are likely other protocols that had issues resolved by these
fixes. I can dig some up if necessary, but I don't really see the
point.
-Dan
On Mon, Nov 15, 2010 at 3:02 PM, Steven M. Christey
<coley@...us.mitre.org> wrote:
>
> 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.
