Attachment 22895 Details for Bug 59194

vulnerability description

Gaim0.81vulnerabilities.txt (text/plain), 6.37 KB, created by Sebastian Krahmer on 2004-08-25 16:41:25 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Sebastian Krahmer

Created: 2004-08-25 16:41:25 UTC

Size: 6.37 KB

patch

obsolete

>-------------------------------------------------------------------------------
>>From http://gaim.sourceforge.net/security.php (and CAN-2004-0500 ?):
>
>AFFECTED CODE:	src/protocols/msn/ object.c and slp.c
>CVE NAME:		
>NAME:			
>SUMMARY:		Possible for a remote MSN user to cause a buffer overflow?
>
>DESCRIPTION:	strncpy was used incorrectly; the size of the array was not checked before copying to it. Both bugs affect MSN's MSNSLP protocol, which is peer-to-peer, so this could potentially be easy to exploit.
>
>FIX:			Bounds checking was added to both places.
>
>-------------------------------------------------------------------------------
>>From http://gaim.sourceforge.net/security.php:
>
>AFFECTED CODE:	src/gtkprefs.c
>CVE NAME:		
>NAME:			Smiley theme filename shell escape
>SUMMARY:		Dragging a carefully crafted smiley theme filename onto Gaim could cause arbitrary command execution.
>
>DESCRIPTION:	To install a new smiley theme, a user can drag a tarball from a graphical file manager, or a hypertext link to one from a web browser. When a tarball is dragged, Gaim executes a shell command to untar it. However, it does not escape the filename before sending it to the shell. Thus, a specially crafted filename could execute arbitrary commands if the user could be convinced to drag a file into the smiley theme selector.
>
>FIX:			Filenames are escaped using g_shell_quote().
>
>-------------------------------------------------------------------------------
>>From Sean (infamous42md@hotpop.com):
>
>AFFECTED CODE:	src/util.c, url_fetched_cb()
>CVE NAME:		N/A
>NAME:			Content-length DOS (malloc error)
>SUMMARY:		Posibile for a malicious web server to provide a web page with a false content-length value which could crash Gaim.
>
>DESCRIPTION:	Remote crash.  When a remote server provides a large "content-length" header value, Gaim will attempt to allocate a buffer to store the content, however this allocation attempt will cause Gaim to crash if the length exceeds the amount of possible memory.  This happens when reading profile information on some protocols.  It also happens when smiley themes are installed via drag and drop.
>
>FIX:			The call to g_malloc() was replaced with a call to g_try_malloc().  If the memory could not be allocated the function returns instead of causing the application to crash.
>
>-------------------------------------------------------------------------------
>>From Sean (infamous42md@hotpop.com):
>
>AFFECTED CODE:	src/util.c, gaim_url_decode()
>CVE NAME:		
>NAME:			URL decode buffer overflow
>SUMMARY:		Receiving exceedingly long URLs can cause a buffer overflow.
>
>DESCRIPTION:	Buffer overflow.  The URL is decoded into a static buffer of length 2048 bytes.  I'm not sure it's possible to receive a URL longer than 2048 bytes, as many protocols have message limits that are shorter than that.
>
>FIX:			A check to make sure the source string is shorter than 2048 bytes is performed.
>-------------------------------------------------------------------------------
>>From Sean (infamous42md@hotpop.com):
>
>AFFECTED CODE:	src/protocols/zephyr/zephyr.c, zephyr_inithosts()
>CVE NAME:		
>NAME:			Local hostname resolution buffer overflow
>SUMMARY:		Possible buffer overflow when resolving the hostname of the local computer.
>
>DESCRIPTION:	Buffer overflow.  If the local computers host name is not in /etc/hosts, and the computer performs a DNS query to obtain it's hostname when signing on to zephyr, it could receive a reply with a hostname greater than MAXHOSTNAMELEN (generally 64 bytes).  If gethostbyname() does not ensure the size of hostent->h_name is less than MAXHOSTNAMELEN, this value would be copied to a buffer that is not large enough.
>
>FIX:			The calls to copy the hostname were replaced with calls that check the length of the destination buffer.
>
>-------------------------------------------------------------------------------
>>From Sean (infamous42md@hotpop.com):
>
>AFFECTED CODE:	src/protocols/novell/nmrtf.c, rtf_parse_keyword()
>CVE NAME:		
>NAME:			RTF message buffer overflow
>SUMMARY:		Invalid rich text format messages could cause a buffer overflow.
>
>DESCRIPTION:	Buffer overflow.  There are some loops that read into fixed-sized buffers and do not check to make sure they are not writing too much.
>
>FIX:			Added bounds checking to the two loops.
>
>-------------------------------------------------------------------------------
>>From Sean (infamous42md@hotpop.com):
>
>AFFECTED CODE:	src/protocols/novell/nmevent.c, handle_receive_message(), ~line 165
>CVE NAME:		
>NAME:			Groupware message receive integer overflow
>SUMMARY:		?
>
>DESCRIPTION:	Integer overflow in memory allocation results in heap overflow.  by passing the size variable as ~0, integer overflows to 0 when 1 is added in g_alloc().   a malloc(0) call results in 16 bytes of memory being allocated on IA- 32.  then we can overflow the heap when nm_read_all() is called next step.  usually cases like this suck for exploitation, b/c the len (~0) is so large that a following call to memcpy() or strcpy() will just run into kernel mem or unmapped address  and fault.  however in this case we read the data from the network via a read() call, so we can just stop sending data and close the connection to short out before ~0 bytes are read.  however, this is triggered by input from the server, not directly from a client.  someone running a malicious groupware server could leverage this to run arbitrary code on the client.
>
>FIX:			Bounds checking was added.
>
>-------------------------------------------------------------------------------
>>From Sean (infamous42md@hotpop.com):
>
>These need to be investigated.  I don't have any info on these besides what I saw on http://www.securityfocus.com/archive/1/371640 (also forwarded to gaim-devel)
>
>[---------------------------------------------]
>
>1. src/protocols/msn/slp.c, msn_slp_sip_recv(), line 648
>
>improper use of strncpy().  
>
>[---------------------------------------------]
>
>2. src/protocols/msn/utils.c, encode_spaces(), line 134
>
>not very interesting for us, but there is a local overflow.  it's not stack based-the buffer is a global so it's somewhere in .bss.  it doesn't check the length of the buffer it copies into.  unless there is some max bounds way higher up in the gtk functions that i missed.
>
>[---------------------------------------------]
>
>3. src/protocols/msn/utils.c, msn_import_html(), line 198
>
>another local (stack based) overflow.  is not exploitable though.  multiple calls to strcat() to a small buffer, but no control over the data being appended.
>

Actions: View

Attachments on bug 59194: 22895 | 22896 | 22899 | 22900 | 22902 | 22904