PuTTY vulnerability vuln-sftp-string

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Vulnerability: crafted SFTP string may allow remote code execution
class: vulnerability: This is a security vulnerability.
difficulty: fun: Just needs tuits, and not many of them.
priority: high: This should be fixed in the next release.
present-in: 0.56 2005-02-20
fixed-in: 0.57 2005-02-21 893d187b81991a7b259ede864b7d18ae60c59589

Many versions of PSFTP and PSCP prior to 0.57 have a heap corruption vulnerability in their treatment of string fields in the SSH File Transfer Protocol (SFTP).

Since a string field is present in the server's response to the FXP_OPEN request, this vulnerability can be triggered by simply connecting to a malicious SFTP server.

(Note however that the vulnerability kicks in after host key verification, so the host key of the server has to have been accepted to get this far.)

SFTP is always used by PSFTP; it is also used by PSCP if available (depending on server behaviour). It can be used in both SSH-2 and SSH-1 (again, depending on server behaviour). Thus, a malicious server can exploit this in all invocations of PSFTP and PSCP, unless the -scp option is supplied to PSCP.

This bug was discovered by a contributor to iDEFENSE's Vulnerability Contributor Program. Along with vuln-sftp-readdir, it is documented in iDEFENSE's advisory 02.21.05, mentioned in Secunia's advisory SA14333, and has been assigned CVE ID CVE-2005-0467. It has also been individually assigned OSVDB ID 14003.

Vulnerability details: If a string length that would read off the end of the SFTP packet was supplied, sftp.c:sftp_pkt_getstring() would not return a pointer to the string, but would return the server-supplied string length. fxp_open_recv() would then call mkstr() with that length; with a carefully crafted length field, mkstr() would malloc(0) due to an integer overflow, and then memcpy() data from *NULL to that location, leading to a heap corruption. (The data copied to the heap is not trivially server-controlled, but it can't be ruled out on all platforms.)

If you want to comment on this web site, see the Feedback page.
Audit trail for this vulnerability.
(last revision of this bug record was at 2019-03-21 07:16:27 +0000)