Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 19 Jan 2012 22:19:23 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Huzaifa Sidhpurwala <huzaifas@...hat.com>,
        Agostino Sarubbo <ago@...too.org>
Subject: Re: CVE request: Wireshark multiple vulnerabilities

On 01/19/2012 09:27 PM, Huzaifa Sidhpurwala wrote:
> On 01/18/2012 11:17 AM, Kurt Seifried wrote:
> On 01/18/2012 11:17 AM, Kurt Seifried wrote:
>> On 01/17/2012 12:46 AM, Huzaifa Sidhpurwala wrote:
>>> On 01/16/2012 01:19 AM, Kurt Seifried wrote:
>>>>
>>>> I agree in principle, however in practice this is a lot of work (as
>>>> you
>>>> well know =). I guess my question/concern would be is who does the
>>>> research to verify all this, and what if it varies by version (i.e. it
>>>> is 6 separate issues in an older version but the newer version
>>>> combined
>>>> some code into a common library for example so it's only a single
>>>> issue,
>>>> but with multiple avenues of attack/etc.). In other words a lot of
>>>> potential work.
>>>
>>>
>>> I did some research, with details available at:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=773726#c2 and
>>> https://bugzilla.redhat.com/show_bug.cgi?id=773726#c3
>>>
>>> In my opinion only 1 and 2 (ie ws bug 6663 and ws bug
>>> 6670) should be allocated a CVE.
>>>
>>> Others are application crashes.
>>
>> Ok doke, so we already got CVE-2012-0041 Assigned for all of these. I
>> slightly re-ordered them from the info at
>> https://bugzilla.redhat.com/show_bug.cgi?id=773726 and an irc chat to
>> confirm:
>>
>> ======
>> Type-cast error: Caused because of casting unsigned to signed int (ws
>> bug
>> 6663). This leaves the app in an unstable state.
>> -
>> 1. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6663
>> This is a type cast issue, caused because of casting an unsigned int to
>> signed
>> int.
>> In the unfixed version this would throw an exception which the
>> application
>> would catch, but leave it in an unstable state. The patch makes sure
>> that the
>> value passed was less than G_MAXINT
>> Patch:
>> http://anonsvn.wireshark.org/viewvc?view=revision&amp;revision=40164
>>
>> =======
>> Application crash/Dos because of trying to allocate too large a
>> buffer size
>> (ws bug 6666, 6667, 6669).
>> -
>> 2. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6666
>> 5Views file format DoS due to request to allocate too large a buffer
>> size.
>> Normally glib should terminate the application with something like
>> "GLib-ERROR **: gmem.c:239: failed to allocate 3221228094 bytes"
>> Resolved by clamping the value of packet_size
>> Patch:
>> http://anonsvn.wireshark.org/viewvc?view=revision&amp;revision=40165
>>
>> 3. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6667
>> Same problem and solution but with i4b capture format now
>> Patch:
>> http://anonsvn.wireshark.org/viewvc?view=revision&amp;revision=40166
>>
>> 5. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6669
>> Similar issue with netmon file format.
>> Patch:
>> http://anonsvn.wireshark.org/viewvc?view=revision&amp;revision=40168
>>
>> =======
>> Integer underflow causing too large buffer to be allocated and a crash
>> (ws bug 6668).
>> -
>> 4. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6668
>> Same problem and solution but with iptrace capture format. Also some
>> checks for
>> bad file format.
>> Patch:
>> http://anonsvn.wireshark.org/viewvc?view=revision&amp;revision=40167
>>
>> =======
>> Memory corruption (buffer-overflow) when reading novell capture file
>> format. glibc however detects this and terminates the application (ws
>> bug 6670)
>> -
>> 6. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6670
>> Similar issue with netmon file format.
>> Patch:
>> http://anonsvn.wireshark.org/viewvc?view=revision&amp;revision=40169
>>
>> =======
>>
>> So we already have one CVE assigned for all these, my thought would be
>> to use CVE-2012-0041 for the first one (6663) and assign new CVE's for
>> the rest. Comments/questions?
>>
>
>
> You are correct, we may need to split this into 4 parts:
>
>
> 6663 - typecast flaw
Please continue to use CVE-2012-0041 for this issue (6663)

> 6666, 6667, 6669 - Dos due to too large buffer alloc requst
Please use CVE-2012-0066 for these issues (6666, 6667, 6669)

> 6668 - Dos due to integer underflow and too large buffer alloc. request
Please use CVE-2012-0067 for this issue (6668)

> 6670 - memory corruption due to buffer underflow
Please use CVE-2012-0068 for this issue (6670)

-- 

-- Kurt Seifried / Red Hat Security Response Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ