Public Vulnerability Reports

Multiple PuTTY SFTP Client Packet Parsing Integer Overflow Vulnerabilities

02.21.05

BACKGROUND

PuTTY is a free implementation of Telnet and SSH for Win32 and Unix
platforms, along with an xterm terminal emulator.

More information is available on the vendor's website:
http://www.chiark.greenend.org.uk/~sgtatham/putty/

DESCRIPTION

Remote exploitation of multiple integer overflow vulnerabilities in
Simon Tatham's PuTTY can allow attackers to execute arbitrary code.

The first vulnerability specifically exists due to insufficient
validation of user-supplied data passed to a memcpy function. The PuTTY
sftp implementation allows attackers to supply arbitrary values for the
stored length of the string in the packet. This may be observed in the
sftp_pkt_getstring() function from sftp.c in PuTTY source code:

static void sftp_pkt_getstring(struct sftp_packet *pkt,
                               char **p, int *length)
{                             
    *p = NULL;
    if (pkt->length - pkt->savedpos < 4)
        return;       
    /* length value is taken from user-supplied data */
    *length = GET_32BIT(pkt->data + pkt->savedpos);
    pkt->savedpos += 4;
    /* this check will be passed if length < 0 */
    if (pkt->length - pkt->savedpos < *length) 
        return;                                 
    *p = pkt->data + pkt->savedpos;
    pkt->savedpos += *length;
}

This function is called from fxp_open_recv() and passes the returned
string pointer and string length to the mkstr() function:


struct fxp_handle *fxp_open_recv(struct sftp_packet *pktin,
                 struct sftp_request *req)
{
    ...
    /* sftp_pkt_getstring call with controlled len value */
    sftp_pkt_getstring(pktin, &hstring, &len); 
    ...
    handle = snew(struct fxp_handle);
    /* heap corruption will occur if len == -1 */
    handle->hstring = mkstr(hstring, len);     
    handle->hlen = len;
    sftp_pkt_free(pktin);
    return handle;
    ...
}

If length is passed as -1, a malloc(0) will occur when the snewn() macro
is called:

static char *mkstr(char *s, int len)
{
    /* malloc(0) if len == -1 */
    char *p = snewn(len + 1, char); 
    /* user controlled heap corruption */
    memcpy(p, s, len);
    p[len] = '';
    return p;
}

Finally, when the memcpy function is called heap corruption will occur
leading to potential code execution.

The second vulnerability specifically exists due to insufficient
validation of user-supplied data passed to a malloc function. This may
be observed in the fxp_readdir_recv() function from PuTTY source code:

struct fxp_names *fxp_readdir_recv(struct sftp_packet *pktin,
                                   struct sftp_request *req) {
        /* 32 bit value from packet */
        ret->nnames = sftp_pkt_getuint32(pktin);
        /*
         * The integer overflow occurs when ret->nnames is referenced
         * the snewn macro calls malloc() wrapper
         * #define snewn(n, type) ((type *)smalloc((n)*sizeof(type)))
         */
        ret->names = snewn(ret->nnames, struct fxp_name);
        for (i = 0; i < ret->nnames; i++) {
            char *str;
            int len;
            sftp_pkt_getstring(pktin, &str, &len);
            /* pointer to arbitrary data from packet */
            ret->names[i].filename = mkstr(str, len);
            sftp_pkt_getstring(pktin, &str, &len);
            /* pointer to arbitrary data from packet */
            ret->names[i].longname = mkstr(str, len);
            /* pointer to arbitrary data from packet */
            ret->names[i].attrs = sftp_pkt_getattrs(pktin);
    }

This function is called from scp_get_sink_action() in scp.c and
sftp_cmd_ls() in sftp.c and can lead to remote code execution via heap
corruption. Sample debugger output of heap corruption is shown below:

psftp> ls
Listing directory /home/test

Program received signal SIGSEGV, Segmentation fault.
0x4009173c in memcpy () from /lib/libc.so.6
(gdb) bt
#0  0x4009173c in memcpy () from /lib/libc.so.6
#1  0x0805675f in mkstr (s=0x4e20 <Address 0x4e20 out of bounds>, len=0)
#2  0x0805748e in fxp_readdir_recv (pktin=0x809bc10, req=0x4e20)
#3  0x0804f7b8 in sftp_cmd_ls (cmd=0x4e20) at ../psftp.c:251
#4  0x08051955 in do_sftp (mode=0, modeflags=0, batchfile=0x0)
#5  0x080525f8 in psftp_main (argc=4, argv=0xbffff494)
#6  0x08080500 in main (argc=20000, argv=0x4e20)
(gdb) up 2
#2  0x0805748e in fxp_readdir_recv (pktin=0x809bc10, req=0x4e20)
952                 ret->names[i].filename = mkstr(str, len);
(gdb) x/8x *(int)pktin
0x80acc58:  0x01000068  0x66666600  0x00000067  0x42424208
0x80acc68:  0x42424242  0x00000042  0x44444408  0x44444444
(gdb) print (struct sftp_packet)pktin
$2 = {data = 0x809bc10 "XÌ YF", length = 134885120,
maxlen = -1073744968, savedpos = 134551097, type = 134885088}

ANALYSIS

Successful exploitation allows remote attackers to execute arbitrary
code under the privileges of the user running PuTTY. The client must be
directed to connect to a malicious server in order to trigger the
vulnerability. It should be noted that this vulnerability may affect
applications which use PuTTY source code or binaries as a SFTP protocol
backend.

DETECTION

iDEFENSE has confirmed that PuTTY 0.56 is vulnerable. It is suspected
that earlier versions are also vulnerable.

The following vendors distribute susceptible PuTTY packages within
their respective operating system distributions:

FreeBSD Project:
 FreeBSD 4.9, 4.10, 5.0, 5.1 and 5.2.1

Gentoo Foundation Inc.:
 Gentoo Linux 1.1a, 1.2, 1.4, 2004.0, 2004.1 and 2004.2
 

WORKAROUND

Use an alternate SFTP client to connect to untrusted hosts until the
vendor releases a patch.

VENDOR RESPONSE

Vendor advisories for these issues are available at:

http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-sftp-string.html

http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-sftp-readdir.html

CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0467 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

DISCLOSURE TIMELINE

02/18/2005   Initial vendor notification
02/19/2005   Initial vendor response
02/21/2005   Public disclosure

CREDIT

Gaël Delalleau credited with this discovery.

Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp

LEGAL NOTICES

Copyright © 2005 Verisign, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice@idefense.com for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.