Bugzilla – Attachment 15668 Details for
Bug 48991
VUL-0: CVE-2004-0007: gaim: 12 buffer overflows
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
IDP Log In
|
Forgot Password
email by stefan esser
gaim.txt (text/plain), 18.33 KB, created by
Thomas Biege
on 2004-01-16 18:05:37 UTC
(
hide
)
Description:
email by stefan esser
Filename:
MIME Type:
Creator:
Thomas Biege
Created:
2004-01-16 18:05:37 UTC
Size:
18.33 KB
patch
obsolete
>From s.esser@e-matters.de Fri Jan 16 11:03:44 2004 >Date: Fri, 16 Jan 2004 01:07:03 +0100 >From: Stefan Esser <s.esser@e-matters.de> >To: vendor-sec@lst.de >Subject: [vendor-sec] PREVIEW: 12 x Gaim remote overflows > >Hello, > >within the next days there will be a new gaim version and I will >release the following advisory (or a slightly different one) > >Please contact me if you need more information. > >Stefan Esser > > e-matters GmbH > www.e-matters.de > > -= Security Advisory =- > > --- PREVIEW VERSION FOR VENDOR SEC --- > > > > Advisory: 12 x Gaim remote overflows > Release Date: ONLY PREVIEW VERSION >Last Modified: ONLY PREVIEW VERSION > Author: Stefan Esser [s.esser@e-matters.de] > > Application: Gaim <= 0.75 > Severity: 12 vulnerabilities in the instant messenger GAIM > were found that allow remote compromise > Risk: Critical >Vendor Status: Gaim vendor has commited my patch to the CVS > Reference: ONLY PREVIEW VERSION > > >Overview: > > Gaim is a multi-protocol instant messaging client for Linux, BSD, > MacOS X, and Windows. It is compatible with AIM (Oscar and TOC > protocols), ICQ, MSN Messenger, Yahoo, IRC, Jabber, Gadu-Gadu, > and Zephyr networks. It is a very popular choice among the users > of instant messaging networks and especially in the community of > migrated windows users. > > While developing a custom add-on, an integer overflow in the > handling of AIM DirectIM packets was revealed that could lead > to a remote compromise of the IM client. After disclosing this > bug to the vendor, they had to make a hurried release because > of a change in the Yahoo connection procedure that rendered > GAIM useless. Unfourtunately at the same time a closer look > onto the sourcecode revealed 11 more vulnerabilities. > > The 12 identified problems range from simple standard stack > overflows, over heap overflows to an integer overflow that can > be abused to cause a heap overflow. Due to the nature of instant > messaging many of these bugs require man-in-the-middle attacks > between client and server. But the underlying protocols are > easy to implement and MIM attacks on ordinary TCP sessions is > a fairly simple task. > > In combination with the latest kernel vulnerabilities or the > habit of users to work as root/administrator these bugs can > result in remote root compromises. > > >Details: > > While auditing the Gaim source code the following 12 > vulnerabilities were discovered: > > Overflows in YMSG protocol (yahoo messenger) handler > ---------------------------------------------------- > > 01) Yahoo Octal-Encoding Decoder Overflow > 02) Yahoo Octal-Encoding Decoder Out-Of-Bounds Overflow > 03) Yahoo Web Cookie Parser Overflow > 04) Yahoo Login Page Name Parser Overflow > 05) Yahoo Login Page Value Parser Overflow > 06) Yahoo Packet Parser Overflow > > Overflows in oscar protocol (AIM) handler > ----------------------------------------- > > 07) AIM/Oscar DirectIM Integer Overflow > > Overflows in utility functions > (called in various protocols) > ------------------------------ > > 08) Quoted Printable Decoder Overflow > 09) Quoted Printable Decoder Out-Of-Bounds Overflow > 10) URL Parser Function Overflow > 11) Extract Info Field Function Overflow > > Overflows that do not fit into > the other categories > ------------------------------ > > 12) HTTP Proxy Connect Overflow > > > Detailed Bug Description > ------------------------ > > [01 - Yahoo Octal-Encoding Decoder Overflow] > [02 - Yahoo Octal-Encoding Decoder Out-Of-Bounds Overflow] > > When the Yahoo Messenger handler decodes an octal value for > email notification functions 2 different kind of overflows > can be triggered > > Affected version: 0.75 (only) > File: gaim/src/protocols/yahoo/yahoo.c > Function: yahoo_decode() > Code: > > static char *yahoo_decode(const char *text) > { > char *converted; > char *p, *n, *new; > > n = new = g_malloc(strlen (text) + 1); > > for (p = (char *)text; *p; p++, n++) { > if (*p == '\\') { > sscanf(p + 1, "%3o\n", (int *)n); <-------- [01] > p += 3; <--------------------------------- [02] > } > else > *n = *p; > } > > *n = '\0'; > ... > > The way sscanf is used, it will always write 4 bytes to the > allocated buffer. The author did not see the possibility of > malformed input like "\1" (the backslash is only a backslash) it > is possible to write 1-2 zero bytes over the buffer boundaries. > On linux this is exploitable like any heap off by one into the > malloc() chunks. The second vulnerability is that no matter how > many bytes sscanf() consumes it always increases the pointer > with assumed 4 bytes. This can result in overjumping the > terminating zero byte and with special prepared memory after > the string it is possible to overwrite the heap with an > arbitrary amount of bytes. > > These bugs are counted as 2 because for most people [02] is not > obvious. As an example the vendor fixed only [01] first, because > my description was not good enough. Additionally the misuse of > sscanf() caused an incompatibility to all big endian platforms. > > > [03 - Yahoo Web Cookie Parser Overflow] > > When parsing the cookies within the HTTP reply header of a > yahoo web connection a bufferoverflow can happen. > > Affected version: <= 0.75 > File: gaim/src/protocols/yahoo/yahoo.c > Function: yahoo_web_pending() > Code: > > void yahoo_web_pending(gpointer data, gint source, ... > { > GaimConnection *gc = data; > GaimAccount *account = gaim_connection_get_account(gc); > struct yahoo_data *yd = gc->proto_data; > char buf[1024], buf2[256], *i = buf, *r = buf2; > int len, o = 0; > > len = read(source, buf, sizeof(buf)); > ... > while ((i = strstr(i, "Set-Cookie: ")) && 0 < 2) { > i += strlen("Set-Cookie: "); > for (;*i != ';'; r++, i++) { > *r = *i; > } > *r=';'; > r++; > ... > } > ... > > Here all cookie data contained in the first 1024 byte of a > HTTP reply header is copied into a 256 byte buffer without > a size check. Because source and destination buffer are > both on the stack and stack layout will most probably > result in the smaller buffer overflowing into the smaller > one this bug is believed to be not exploitable with the > normal stack layout. Note also the typo in the while() > condition 0 < 2 which should be o < 2 > > > [04 - Yahoo Login Page Name Parser Overflow] > [05 - Yahoo Login Page Value Parser Overflow] > > When parsing the Yahoo Login Webpage the YMSG protocol overflows > stachbuffers if the webpage returns oversized values. > > Affected version: <= 0.75 > File: gaim/src/protocols/yahoo/yahoo.c > Function: yahoo_login_page_hash() > Code: > > static > GHashTable *yahoo_login_page_hash(const char *buf,size_t len) > { > GHashTable *hash = g_hash_table_new_full(g_str_hash, g_s... > const char *c = buf; > char *d; > char name[64], value[64]; > while ((c < (buf + len)) && (c = strstr(c, "<input "))) { > c = strstr(c, "name=\"") + strlen("name=\""); > for (d = name; *c!='"'; c++, d++) <----------- [04] > *d = *c; <---------/ > *d = '\0'; > d = strstr(c, "value=\"") + strlen("value=\""); > if (strchr(c, '>') < d) > break; > for (c = d, d = value; *c!='"'; c++, d++) <--- [05] > *d = *c; <-----------------------------/ > *d = '\0'; > g_hash_table_insert(hash, g_strdup(name), g_strdup(value)); > } > return hash; > } > > The content of the yahoo login webpage is trusted although it > could be changed with a simple man-in-the-middle attack on the > HTTP session. name and value are filled directly from the page > without any kind of size check. This results in two independent > ways to overflow the stack. > > > [06 - Yahoo Packet Parser Overflow] > > A Yahoo Messenger packet consist of a header and a list of keys > with their associated values. When reading an oversized keyname > a standard stackoverflow can be triggered. This is nost probably > the most dangerous discovered vulnerability because the nature > of the bug makes it very easy to exploit and additonally a TCP > man-in-the-middle attack is NOT needed. It is possible to send > a malicious YMSG packet to the yahoo server so that it will > be forwarded like any normal message. > > Affected version: <= 0.75 > File: gaim/src/protocols/yahoo/yahoo.c > Function: yahoo_packet_read() > Code: > > static void yahoo_packet_read(struct yahoo_packet *pkt, > guchar *data, int len) > { > int pos = 0; > > while (pos + 1 < len) { > char key[64], *value = NULL, *esc; > int accept; > int x; > > struct yahoo_pair *pair = g_new0(struct yahoo_pair, 1); > > x = 0; > while (pos + 1 < len) { > if (data[pos] == 0xc0 && data[pos + 1] == 0x80) > break; > key[x++] = data[pos++]; <----------------- [06] > } > key[x] = 0; > pos += 2; > ... > > Everytime the YMSG handler receives a complete packet it will > give it this function to split it into its keys and values. > Because the keyname is copied without any kind of size check > into the key variable which is a 64 byte stackbuffer it is very > easy to exploit. > > > [07 - AIM/Oscar DirectIM Integer Overflow] > > Integer Overflow when allocating memory for a directIM packet > results in heap overflow. directIM is a client 2 client protocol > and therefore does not require a mim. > > Affected version: 0.75 (only) > File: gaim/src/protocols/oscar/ft.c > Function: handlehdr_odc() > Code: > > static int handlehdr_odc(aim_session_t *sess, aim_... > { > aim_frame_t fr; > int ret = 0; > aim_rxcallback_t userfunc; > fu32_t payloadlength; > fu16_t flags, encoding; > char *snptr = NULL; > > fr.conn = conn; > > /* AAA - ugly */ > aim_bstream_setpos(bs, 20); > payloadlength = aimbs_get32(bs); > > ... > > if (payloadlength) { > char *msg; > ... > > if (!(msg = calloc(1, payloadlength+1))) { <--- [07] > free(snptr); > return -ENOMEM; > } > > while (payloadlength - recvd) { > if (payloadlength - recvd >= 1024) > i = aim_recv(conn->fd, &msg[recvd], 1024); > else > ... > > Within this code snipset payloadlength is taken directly from the > network and passed to the calloc() function in an unsafe manner. > > A user supplied payloadlength of UINT_MAX (0xffffffff) will cause > an integer overflow within the second parameter of calloc() and > therefore only allocate a 0 byte buffer. Please notice that this > bug is not an integer overflow due to the multiplication within > calloc() and therefore it is not catched by the recent security > patches to calloc() on different platforms. Please also note that > calloc(1, 0) will not return a NULL pointer but a pointer into > the legal heap on at least all tested platforms (f.e. linux, bsd) > On BSD systems this is configureable but it defaults to this > behaviour. After allocating the 0 byte buffer aim_recv() is called > repeatedly by the while loop to read and overwrite with up to 4GB > of data. > > > [08 - Quoted Printable Decoder Overflow] > [09 - Quoted Printable Decoder Out-Of-Bounds Overflow] > > When the MIME decoder decosed a quoted printable encoded string > for email notification 2 different kind of overflows can be > triggered. > > Affected version: 0.75 (only) > File: gaim/src/util.c > Function: quotedp_decode() > Code: > > void > gaim_quotedp_decode(const char *str, char **ret_str, int ... > { > char *p, *n, *new; > > n = new = g_malloc(strlen (str) + 1); > > for (p = (char *)str; *p; p++, n++) { > if (*p == '=') { > sscanf(p + 1, "%2x\n", (int *)n); <-------- [08] > p += 2; <--------------------------------- [09] > } > else if (*p == '_') > *n = ' '; > else > *n = *p; > } > > *n = '\0'; > ... > > Because these bugs are very similar to [01] and [02] only the > vulnerable code snipset is shown here. For an explanation read > the yahoo_decode() vulnerability description. > > > [10 - URL Parser Function Overflow] > > At various placed this utility function is used to split an > url into its parts. Because temporary fixed size stackbuffers > are used in an unsafe way a standard stackoverflow can be > caused. > > Affected version: <= 0.75 > File: gaim/src/util.c > Function: gaim_url_parse() > Code: > > gboolean > gaim_url_parse(const char *url, char **ret_host, > int *ret_port, char **ret_path) > { > char scan_info[255]; > char port_str[5]; > int f; > const char *turl; > char host[256], path[256]; > int port = 0; > /* hyphen at end includes it in control set */ > static char addr_ctrl[] = "A-Za-z0-9.-"; > static char port_ctrl[] = "0-9"; > static char page_ctrl[] = "A-Za-z0-9.~_/:*!@&%%?=+^-"; > > ... > g_snprintf(scan_info, sizeof(scan_info), > "%%[%s]:%%[%s]/%%[%s]", addr_ctrl, > port_ctrl, page_ct > > f = sscanf(url, scan_info, host, port_str, path); <-- [10] > ... > > Here sscanf() is again used in an unsafe manner. When this > function is called with an oversized url, which can be triggered > from several protocol handlers in different ways sscanf() will > overwrite the stackbuffers host and path. The problem at this > point is, that it is only possible to overwrite the buffers with > a limited characterset which makes exploitation tricky. > > > [11 - Extract Info Field Function Overflow] > > At various places this utility function is called to copy the > data between 2 tokens into a fixed size stackbuffer without a > size check. > > Affected version: <= 0.74 > File: gaim/src/util.c > Function: gaim_markup_extract_info_field() > Code: > > ... > const char *p, *q; > char buf[1024]; > > ... > p = strstr(str, start_token); > ... > p += strlen(start_token) + skip; > ... > q = strstr(p, end_token); > > if (q != NULL && (!no_value_token || > (no_value_token && strncmp(p, no_value > > { > ... > if (is_link) > { > strcat(dest_buffer, "<br><a href=\""); > memcpy(buf, p, q - p); <---------------------- [11] > buf[q - p] = '\0'; > ... > > Here it is obvious that if q - p is bigger than 1024 bytes > memcpy() will overwrite the stack which will result in a > standard stack overflow. At the moment this routine is > called from within the get_user_info functions of the MSN > and YMSG protocol handlers. > > > [12 - HTTP Proxy Connect Overflow] > > When Gaim is setup to use a HTTP proxy for connecting to the > server a malicious HTTP proxy can exploit it. > > Affected version: <= 0.75 > File: gaim/src/proxy.c > Function: http_canread() > Code: > > static void > http_canread(gpointer data, gint source, GaimInputCondit... > { > int nlc = 0; > int pos = 0; > int minor, major, status, error=0; > struct PHB *phb = data; > char inputline[8192], *p; > > gaim_input_remove(phb->inpa); > > while ((nlc != 2) && > (read(source, &inputline[pos++], 1) == 1)) { > if (inputline[pos - 1] == '\n') > nlc++; > else if (inputline[pos - 1] != '\r') > nlc = 0; > } > inputline[pos] = '\0'; > ... > > Here the author never thought about the possibility that a > proxy server could be malicious. The inputline is read into > the 8192 byte buffer byte after byte until a double \r\n is > found. Because there is no size check at all the buffer will > overflow as soon the proxy sends more than 8192 bytes in a > line. This bug is exploitable even if stack overwrite > protections are in place because it is possible to overwrite > the pointer phb which points to a struct that contains a > callback function which is later called in the function. > By overwriting the pointer and so controlling the callback > function pointer it is possible to gain control over the > instruction pointer before the function is left. > > >Proof of Concept: > > e-matters is not going to release exploit for any of the these > vulnerability to the public. > > >Disclosure Timeline: > > ONLY PREVIEW VERSION > > >Recommendation: > > ONLY PREVIEW VERSION > > >GPG-Key: > > http://security.e-matters.de/gpg_key.asc > > pub 1024D/75E7AAD6 2002-02-26 e-matters GmbH - Securityteam > Key fingerprint = 43DD 843C FAB9 832A E5AB CAEB 81F2 8110 75E7 AAD6 > > >Copyright 2004 Stefan Esser. All rights reserved. > >-- > >-------------------------------------------------------------------------- > Stefan Esser s.esser@e-matters.de > e-matters Security http://security.e-matters.de/ > > GPG-Key gpg --keyserver pgp.mit.edu --recv-key 0xCF6CAE69 > Key fingerprint B418 B290 ACC0 C8E5 8292 8B72 D6B0 7704 CF6C AE69 >-------------------------------------------------------------------------- > Did I help you? Consider a gift: http://wishlist.suspekt.org/ >-------------------------------------------------------------------------- > >_______________________________________________ >Vendor Security mailing list >Vendor Security@lst.de >https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
Actions:
View
Attachments on
bug 48991
: 15668 |
15738
|
15739
|
15740