PuTTY bug pscp-unsanitised-server-output

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

summary: PSCP should strip unprintable characters from SCP server output
class: bug: This is clearly an actual problem we want fixed.
difficulty: tricky: Needs many tuits.
priority: high: This should be fixed in the next release.
present-in: 0.70

When PSCP is downloading files from a server, it writes the names of the copied files to its standard output as part of progress reports. Also, if the SCP server writes data to its standard error channel, then PSCP will pass that through to its own standard error.

In neither case does PSCP take any care to sanitise the output. So if a server really wants to, it can corrupt the display of the terminal you run PSCP in, by sending escape sequences or other control characters such as backspace.

This isn't really part of the implied contract between an SCP client and its user (unlike Plink, which wouldn't be doing its job if it didn't pass through all the server's output unmodified). It would be better to sanitise the output down to just printable characters and newlines, and perhaps also to prefix server stderr data with something that made it clearly look like a different kind of thing from file download progress reports.

This bug was found and reported by Harry Sintonen as part of a piece of security research. It has two CVE numbers: CVE-2019-6109 (relating to file names sent by the server) and CVE-2019-6110 (relating to the server's stderr stream).

However, in spite of the existence of CVE numbers, we regard this as only a bug, not a vulnerability. In the context of Harry Sintonen's full advisory, the server's ability to send escape sequences is dangerous because it can be used to hide the evidence of having exploited a more serious vulnerability that lets an SCP server write to the client's filesystem in ways the client did not intend to permit. But the research found that PSCP does not have that more serious vulnerability (though other SCP clients did). So in our case, the server wouldn't be able to perform that attack in the first place, and would gain no benefit from the ability to hide the evidence of it.


If you want to comment on this web site, see the Feedback page.
Audit trail for this bug.
(last revision of this bug record was at 2019-01-18 21:24:52 +0000)