Home page logo
/

oss-sec logo oss-sec mailing list archives

Re: CVE request: Wireshark multiple vulnerabilities
From: Kurt Seifried <kseifried () redhat com>
Date: Thu, 19 Jan 2012 22:19:23 -0700

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]