This article is more than 1 year old

Oh, SSH, IT please see this: Malicious servers can fsck with your PC's files during scp slurps

Data transfer tools caught not checking what exactly they're downloading

A decades-old oversight in the design of Secure Copy Protocol (SCP) tools can be exploited by malicious servers to unexpectedly alter victims' files on their client machines, it has emerged.

F-Secure's Harry Sintonen discovered a set of five CVE-listed vulnerabilities, which can be abused by evil servers to overwrite arbitrary files on a computer connected via SCP. If you use a vulnerable version of OpenSSH's scp, PuTTY's PSCP, or WinSCP, to securely transfer files from a remote server, that server may be able to secretly tamper with files on your local box that you do not expect the server to change.

It's a subtle threat because a malicious SCP server can vandalize any files you fetch. After all, if you download ~/example.txt, the received data may be modified just before transit by a malicious server. The key thing here, though, is that a malicious SCP server can alter files on your local machine other than the ones you fetched, or change access permissions, or download extra documents.

Sintonen explained that because rcp, on which scp is based, allows a server to control which files are sent, and without the scp client thoroughly checking it's getting its expected objects, an attacker can do things like overwrite the user's .bash_aliases file. This, in turn, would allow the attacker to run arbitrary commands on the victim's box when the user does routine stuff, like list a directory.

"Many scp clients fail to verify if the objects returned by the scp server match those it asked for. This issue dates back to 1983 and rcp, on which scp is based," Sintonen explained in his disclosure this month.

"A separate flaw in the client allows the target directory attributes to be changed arbitrarily. Finally, two vulnerabilities in clients may allow server to spoof the client output."

Here's a summary of the cockups:

  1. CVE-2018-20685 (scp): "The scp client allows server to modify permissions of the target directory by using empty ('D0777 0 \n') or dot ('D0777 0 .\n') directory name."
  2. CVE-2019-6111 (scp) and CVE-2018-20684 (WinSCP): "The server chooses which files/directories are sent to the client. A malicious scp server can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example overwrite .ssh/authorized_keys)."
  3. CVE-2019-6109 (scp and PSCP): "The object name can be used to manipulate the client output for example, to employ ANSI codes to hide additional files being transferred."
  4. CVE-2019-6110 (scp and PSCP): "A malicious server can manipulate the client output, for example to employ ANSI codes to hide additional files being transferred."

Here's a table of affected versions and CVE numbers:

Package Affected Versions CVE-2018
OpenSSH scp <=7.9 Yes Yes Yes Yes
PuTTY PSCP Unknown     Yes Yes
WinSCP in SCP mode <=5.13   Yes    

The researcher said he would post proof-of-concept examples for the bugs at a later date. He alerted the developers of scp, WinSCP, PSCP in August last year.

CVE-2018-20685 (vulnerability 1) was patched in OpenSSH's scp in mid-November though this has not been formally released. That bug plus CVE-2019-6111 (2), CVE-2019-6109 (3), and CVE-2019-6110 (4), apparently remain unpatched in the latest version, 7.9, released in October. If you're worried about an evil server pwning you, Sintonen has a source-code fix here you can apply by hand, although there are caveats. Alternatively, systems can be configured not to use SCP.

WinSCP was fixed in version 5.14, released last October, and the current version is 5.14.4. It seems unlikely that PuTTY has been fixed yet, since the last release was version 0.7 in July 2017.

Sintonen has a history of January disclosures: last year, he broke news of a bug in Intel's Active Management Technology, and the previous year it was QNAP NAS boxen. ®

Additional reporting by Richard Chirgwin.

Similar topics


Send us news

Other stories you might like