PuTTY vulnerability vuln-pscp-sink-sscanf

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 · Pre-release · Snapshot | Docs | Privacy | Changes | Wishlist

summary: Vulnerability: old-style scp downloads 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.66
fixed-in: 0.67 bc6c15ab5f636e05b7e91883f0031a7e06117947

Many versions of PSCP prior to 0.67 have a stack corruption vulnerability in their treatment of the 'sink' direction (i.e. downloading from server to client) of the old-style SCP protocol.

In order for this vulnerability to be exploited, the user must connect to a malicious server and attempt to download any file.

(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.)

This vulnerability only arises in the old SCP protocol, so you can work around it in a vulnerable PSCP by using the -sftp option to force the use of the newer SFTP protocol, provided your server supports that protocol.

This bug was discovered by tintinweb and has been assigned CVE ID CVE-2016-2563.

Vulnerability details: Prior to any download in the SCP sink protocol, the server sends a line of text consisting of an octal number encoding Unix file permissions, a decimal number encoding the file size, and the file name. Since the file size can exceed 232 bytes, and in some compilation configurations of PuTTY the host platform's largest integer type is only 32 bits wide, PuTTY extracts the decimal file size into a temporary string variable to send to its own 64-bit decimal decoding function. Unfortunately, that extraction was done carelessly, using a sscanf with no length limit, permitting a buffer overrun.


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)