Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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&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?
>


-- 
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&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
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

Your e-mail address:

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

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