Attachment 15668 Details for Bug 48991

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:

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

Actions: View

Attachments on bug 48991: 15668 | 15738 | 15739 | 15740