[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Jan 2012 09:57:59 +0530
From: Huzaifa Sidhpurwala <huzaifas@...hat.com>
To: oss-security@...ts.openwall.com
CC: Kurt Seifried <kseifried@...hat.com>, Agostino Sarubbo <ago@...too.org>,
"Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE request: Wireshark multiple vulnerabilities
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&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&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&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&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&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&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?
>
--
Huzaifa Sidhpurwala / Red Hat Security Response Team
> 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&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&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&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&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&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&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
6666, 6667, 6669 - Dos due to too large buffer alloc requst
6668 - Dos due to integer underflow and too large buffer alloc. request
6670 - memory corruption due to buffer underflow
--
Huzaifa Sidhpurwala / 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
