Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [NT] Multiple Integer Overflow Vulnerabilities In PuTTY SFTP |
|---|---|
| Date: | 22 Feb 2005 15:52:17 +0200 |
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com - - promotion The SecuriTeam alerts list - Free, Accurate, Independent. Get your security news from a reliable source. http://www.securiteam.com/mailinglist.html - - - - - - - - - Multiple Integer Overflow Vulnerabilities In PuTTY SFTP ------------------------------------------------------------------------ SUMMARY <http://www.chiark.greenend.org.uk/~sgtatham/putty/> PuTTY is "a free implementation of Telnet and SSH for Win32 and Unix platforms, along with an xterm terminal emulator". Simon Tatham's PuTTY has been found to contain multiple remote integer overflow vulnerabilities . DETAILS Vulnerable Systems: * PuTTY version 0.56 Successful exploitation of an Integer overflow 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. One such product would be WinSCP3, a popular graphical sftp/scp application for Windows. First Integer Overflow: The PuTTY sftp implementation allows attackers to supply arbitrary values for the stored length of the string in the packet due to insufficient validation of user-supplied data passed to a memcpy function. Vulnerable code:
From sftp.c
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;
}
The usage of the above function is called in fxp_open_recv 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 in the mkstr function, 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, an heap corruption will occur
leading to potential code execution.
Second Integer Overflow:
The second vulnerability specifically exists due to insufficient
validation of user-supplied data passed to a malloc function.
Vulnerable 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:
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 \n\bYF", length = 134885120,
maxlen = -1073744968, savedpos = 134551097, type = 134885088}
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-stringhtml
<http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-sftp-readdir.html>
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-sftp-readdir.html
Disclosure Timeline:
02/18/2005 - Initial vendor notification
02/19/2005 - Initial vendor response
02/21/2005 - Public disclosure
ADDITIONAL INFORMATION
The information has been provided by
<mailto:idlabs-advisories@idefense.com> idlabs-advisories@idefense.com.
The original article can be found at:
<http://www.idefense.com/application/poi/display?id=201>
http://www.idefense.com/application/poi/display?id=201
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [UNIX] SQL Injection in CitrusDB, SecuriTeam |
|---|---|
| Next by Date: | [NT] Multiple Vulnerabilities in WebConnect (Directory Traversal, DoS), SecuriTeam |
| Previous by Thread: | [UNIX] SQL Injection in CitrusDB, SecuriTeam |
| Next by Thread: | [NT] Multiple Vulnerabilities in WebConnect (Directory Traversal, DoS), SecuriTeam |
| Indexes: | [Date] [Thread] [Top] [All Lists] |