ID: 00153
Ref: 137/2005
Date: 22 February 2005:13:36:02
Version: 1
Title: iDEFENSE Security Advisory 02.21.05: Multiple PuTTY SFTP Client Packet Parsing Integer Overflow Vulnerabilities
Abstract: PuTTY is a free implementation of Telnet and SSH for Win32 and Unix platforms, along with an xterm terminal emulator. Remote exploitation of multiple integer overflow vulnerabilities can allow attackers to execute arbitrary code.
Multiple PuTTY SFTP Client Packet Parsing Integer Overflow Vulnerabilities
iDEFENSE Security Advisory 02.21.05: www.idefense.com/application/poi/display?id=201&type=vulnerabilities
February 21, 2005
I. 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/
II. 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] = '\0';
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
, 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Ì\n\bYF", length = 134885120,
maxlen = -1073744968, savedpos = 134551097, type = 134885088}
III. 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 SSH protocol
backend. An example of one such product would be WinSCP3, a popular
graphical sftp/scp application for Windows.
IV. 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
V. WORKAROUND
Use an alternate SSH client to connect to untrusted hosts until the
vendor releases a patch.
VI. 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
VII. 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.
VIII. DISCLOSURE TIMELINE
02/18/2005 Initial vendor notification
02/19/2005 Initial vendor response
02/21/2005 Public disclosure
IX. CREDIT
Gaël Delalleau credited with this discovery.
Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp
X. LEGAL NOTICES
Copyright © 2005 iDEFENSE, 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.