|
There is an integer overflow found in gaim/src/protocols/oscar/ft.c in the handlehdr_odc() function when allocating memory for a directIM packet. The affected code is as follows:
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
...
snipset payloadlength is taken directly from the network and passed to the calloc() function without safe input validation taking place. If a user crafts a packet with a payloadlength of UINT_MAX (0xffffffff), calloc()'s second parameter will be subject to an integer overflow, and will therefore only allocate a 0 byte buffer. This integer overflow is not due to the multiplication within calloc(), and therefore is not fixed by the recent security patches to calloc() on different platforms. calloc(1, 0) will not return a NULL pointer, but will instead return a pointer into the legal heap on all the platforms the vulnerability researcher tested. On BSD systems, this behaviour is configureable, but the erroneous behaviour is the default. 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.
|