|
|
Log in / Subscribe / Register

An ancient OpenSSH vulnerability

An advisory from Harry Sintonen describes several vulnerabilities in the scp clients shipped with OpenSSH, PuTTY, and others. "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. 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." The outcome is that a hostile (or compromised) server can overwrite arbitrary files on the client side. There do not yet appear to be patches available to address these problems.


From:  Harry Sintonen <security-advisories-AT-kyber.fi>
To:  oss-security-AT-lists.openwall.com
Subject:  [oss-security] SCP client multiple vulnerabilities
Date:  Mon, 14 Jan 2019 09:51:43 +0200 (EET)
Message-ID:  <alpine.DEB.2.20.1901140949460.17855@o7.fi>
Archive-link:  Article

scp client multiple vulnerabilities
===================================
The latest version of this advisory is available at:
https://sintonen.fi/advisories/scp-client-multiple-vulner...


Overview
--------

SCP clients from multiple vendors are susceptible to a malicious scp server performing
unauthorized changes to target directory and/or client output manipulation.


Description
-----------

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


Impact
------

Malicious scp server can write arbitrary files to scp target directory, change the
target directory permissions and to spoof the client output.


Details
-------

The discovered vulnerabilities, described in more detail below, enables the attack
described here in brief.

1. The attacker controlled server or Man-in-the-Middle(*) attack drops .bash_aliases
    file to victim's home directory when the victim performs scp operation from the
    server. The transfer of extra files is hidden by sending ANSI control sequences
    via stderr. For example:

    user@local:~$ scp user@remote:readme.txt .
    readme.txt                                         100%  494     1.6KB/s   00:00
    user@local:~$

2. Once the victim launches a new shell, the malicious commands in .bash_aliases get
    executed.


*) Man-in-the-Middle attack does require the victim to accept the wrong host
    fingerprint.


Vulnerabilities
---------------

1. CWE-20: scp client improper directory name validation [CVE-2018-20685]

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. CWE-20: scp client missing received object name validation [CVE-2019-6111]

Due to the scp implementation being derived from 1983 rcp [1], the server chooses which
files/directories are sent to the client. However, scp client only perform cursory
validation of the object name returned (only directory traversal attacks are prevented).
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).

The same vulnerability in WinSCP is known as CVE-2018-20684.


3. CWE-451: scp client spoofing via object name [CVE-2019-6109]

Due to missing character encoding in the progress display, the object name can be used
to manipulate the client output, for example to employ ANSI codes to hide additional
files being transferred.


4. CWE-451: scp client spoofing via stderr [CVE-2019-6110]

Due to accepting and displaying arbitrary stderr output from the scp server, a
malicious server can manipulate the client output, for example to employ ANSI codes
to hide additional files being transferred.


Proof-of-Concept
----------------

Proof of concept malicious scp server will be released at a later date.


Vulnerable versions
-------------------

The following software packages have some or all vulnerabilities:

                    ver      #1  #2  #3  #4
OpenSSH scp        <=7.9    x   x   x   x
PuTTY PSCP         ?        -   -   x   x
WinSCP scp mode    <=5.13   -   x   -   -

Tectia SSH scpg3 is not affected since it exclusively uses sftp protocol.


Mitigation
----------

1. OpenSSH

1.1 Switch to sftp if possible

1.2 Alternatively apply the following patch to harden scp against most server-side
     manipulation attempts: https://sintonen.fi/advisories/scp-name-validator.patch

     NOTE: This patch may cause problems if the the remote and local shells don't
     agree on the way glob() pattern matching works. YMMV.

2. PuTTY

2.1 No fix is available yet

3. WinSCP

3.1. Upgrade to WinSCP 5.14 or later



Similar or prior work
---------------------

1. CVE-2000-0992 - scp overwrites arbitrary files


References
----------

1. https://www.jeffgeerling.com/blog/brief-history-ssh-and-r...


Credits
-------

The vulnerability was discovered by Harry Sintonen / F-Secure Corporation.


Timeline
--------

2018.08.08  initial discovery of vulnerabilities #1 and #2
2018.08.09  reported vulnerabilities #1 and #2 to OpenSSH
2018.08.10  OpenSSH acknowledged the vulnerabilities
2018.08.14  discovered & reported vulnerability #3 to OpenSSH
2018.08.15  discovered & reported vulnerability #4 to OpenSSH
2018.08.30  reported PSCP vulnerabilities (#3 and #4) to PuTTY developers
2018.08.31  reported WinSCP vulnerability (#2) to WinSCP developers
2018.09.04  WinSCP developers reported the vulnerability #2 fixed
2018.11.12  requested a status update from OpenSSH
2018.11.16  OpenSSH fixed vulnerability #1
2019.01.07  requested a status update from OpenSSH
2019.01.08  requested CVE assignments from MITRE
2019.01.10  received CVE assignments from MITRE
2019.01.11  public disclosure of the advisory
2019.01.14  added a warning about the potential issues caused by the patch


to post comments

An ancient OpenSSH vulnerability

Posted Jan 15, 2019 16:31 UTC (Tue) by asn (subscriber, #62311) [Link] (27 responses)

The 'scp' command should simply be replaced with a sftp client. Than we would get rid of that horrible protocol.

An ancient OpenSSH vulnerability

Posted Jan 15, 2019 18:32 UTC (Tue) by Shadowchaser (subscriber, #129388) [Link]

It's one the best things ever created.

An ancient OpenSSH vulnerability

Posted Jan 15, 2019 18:52 UTC (Tue) by job (guest, #670) [Link] (13 responses)

rsync has been pretty much a drop in replacement for scp for 20 years.

As a bonus it sports a drastically more useful feature set, such as continuing botched transfers by default.

An ancient OpenSSH vulnerability

Posted Jan 15, 2019 18:57 UTC (Tue) by cyperpunks (subscriber, #39406) [Link] (1 responses)

How is ssh transport implemented in rsync? Not via scp I hope...

An ancient OpenSSH vulnerability

Posted Jan 15, 2019 19:15 UTC (Tue) by asn (subscriber, #62311) [Link]

It just uses the transport to talk to rsync on the other side similar to scp.

An ancient OpenSSH vulnerability

Posted Jan 15, 2019 20:19 UTC (Tue) by zblaxell (subscriber, #26385) [Link]

In the 90's I was lined up to do a security audit of the rcp code (and some of its contemporaries like rdist and kcp) before putting it into production. Like the rest of the BSD net tools, rcp was written in C by developers who showed no evidence of understanding basic concepts like string quoting or boundary checking. It was likely rcp would fail the audit, so I would have preferred to skip the audit and start building a replacement tool immediately. Alas, I had a boss who disagreed, so I was slated to audit rcp and then throw it away based on concrete evidence and data instead of throwing it away based on reasonable estimates and provenance.

I never did the audit. All the work was preempted one day by the discovery of a shiny new program called 'rsync'.

'rcp' became so completely unnecessary that nobody noticed when the binaries disappeared from production boxes. I don't think we ever installed scp or sftp from the ssh package. Why would we? Everything we installed in production needed to pass a security audit(*), and we already had rsync.

(*) Of course this was before blindly trusting entire binary packages from distros became the norm, and well before a minor web service would have hundred-million-line dependencies in multiple languages to read before deploying. Different times...

An ancient OpenSSH vulnerability

Posted Jan 15, 2019 20:51 UTC (Tue) by Baughn (subscriber, #124425) [Link] (5 responses)

rsync requires rsync to be installed on the server side, which unfortunately isn't always the case.

An ancient OpenSSH vulnerability

Posted Jan 15, 2019 22:19 UTC (Tue) by lkundrak (subscriber, #43452) [Link] (1 responses)

You can always scp it to the remote.
Oh,
wait...

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 3:06 UTC (Wed) by pabs (subscriber, #43278) [Link]

The vulnerabilities are about the other direction, scp from the remote machine to the local machine.

An ancient OpenSSH vulnerability

Posted Jan 15, 2019 22:21 UTC (Tue) by Pc5Y9sbv (guest, #41328) [Link] (2 responses)

Well, a system without rsync is when you start having to carbon-date the system to decide how best to proceed. How long will it take to upload an rsync daemon binary to use with --rsync-path?

Can you coax sshd into invoking a shell redirection? Does it even have a normal shell? Can you turn off ssh pseudo-terminal allocation and get an 8-bit clean pipeline? Does it have base64 commands or perhaps uuencode/uudecode? Maybe something that understands xmodem/ymodem/zmodem?

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 8:40 UTC (Wed) by fwiesweg (guest, #116364) [Link] (1 responses)

Well there are hosters of cheap PHP webspace advertising everything beyond scp as a premium feature, including rsync, and go a long way to stop you using it. So for price sensitive customers, I actually stumbled over such cases...

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 10:17 UTC (Wed) by ibukanov (subscriber, #3942) [Link]

Did those boxes really get only scp and not sftp?

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 17:33 UTC (Wed) by frostsnow (subscriber, #114957) [Link] (2 responses)

How is 'rsync' a drop-in replacement for 'scp'? Last I checked 'rsync' doesn't have any kind of authentication or confidentiality mechanism built into it.

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 17:56 UTC (Wed) by dskoll (subscriber, #1630) [Link]

I think the OP meant that rsync, like scp, uses SSH (or at least, can use SSH) as the transport.

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 17:58 UTC (Wed) by smcv (subscriber, #53363) [Link]

rsync's daemon mode (accessed with syntax "server::remotefile" on the client) doesn't have authentication or confidentiality, but it's hopefully more common to use `rsync localfile server:remotefile`, which tunnels communications over ssh, or more precisely an arbitrary ssh-compatible command (just like scp does).

An ancient OpenSSH vulnerability

Posted Jan 17, 2019 10:50 UTC (Thu) by mgedmin (guest, #34497) [Link]

> As a bonus it sports a drastically more useful feature set, such as continuing botched transfers by default.

Oh, was it changed so --partial is default now? I remember being very disappointed once, more than a decade ago, to discover that rsync deleted the 80%-completed copy of a multi-gigabyte file because I didn't know enough to pass --partial on the command line.

The manual page on my machine claims that --partial is still not default, so what do you mean about continuation by default? Multi-file transfers?

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 6:37 UTC (Wed) by joib (subscriber, #8541) [Link] (5 responses)

What's so bad about the scp protocol, and in which way is sftp better?

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 8:05 UTC (Wed) by asn (subscriber, #62311) [Link] (4 responses)

sftp is a protocol with at least a RFC draft. The OS implementations implement http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02 with some extensions (e.g. statvfs).

scp is a tool which needs to be installed on the client and server. scp talks over a ssh channel to each other using and obscure plain text protocol.

For example to get a file you send: 'C0644 29 a'

downloading file 'a', size 29, perms 0644

The first char is what it is or what to get:

C = file
D = directory
E = enddir
0x2 = error
T = timestamp

it is not very flexible. Compare it to the protocol above for sftp.

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 14:30 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

scp is a tool which needs to be installed on the client and server. scp talks over a ssh channel to each other using and obscure plain text protocol.
Technically the same is usually true of sftp -- it's just that the server-side sshd runs the binary automatically using the subsystem mechanism. There's still a separate binary: in OpenSSH, /usr/libexec/sftp-server. (Though it is true that implementations can exist that implement this subsystem inside sshd itself, I can't see what benefits this would bring.)

sftp itself just invokes ssh -s sftp ... and chatters over the resulting connection: sftp-server just reads on stdin and writes on stdout to do its communication. This is exactly what scp does, except the scp client runs scp directly. But oh my god is the scp code disgusting, gross enough that this on its own should be enough to rule out use of scp anywhere, if it wasn't that sftp(1) doesn't let you do one-liner copies the way scp does. Its provenance stands out a mile when you look at these two fragments. First, this, at global scope:

char cmd[CMDNEEDS];             /* must hold "rcp -r -p -d\0" */

Then this, near the end of main():

        /* Command to be executed on remote system using "ssh". */
        (void) snprintf(cmd, sizeof cmd, "scp%s%s%s%s",
            verbose_mode ? " -v" : "",
            iamrecursive ? " -r" : "", pflag ? " -p" : "",
            targetshouldbedirectory ? " -d" : "");

So it never holds what the comment says it must hold. And it just gets worse from there. (The sftp code is a model of clarity by comparison.)

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 19:18 UTC (Wed) by Pc5Y9sbv (guest, #41328) [Link] (2 responses)

Yes, and I'm noticing that most of the other comments are off the mark a bit as far as the actual vulnerability.

The problem is not "the protocol" but whether a client is written defensively against a potentially unreliable or malicious server peer. As long as the desired UX includes "transfer file content and metadata according to server instructions," we have a big risk. Any mitigation amounts to a sandboxing strategy to filter and validate the server instructions to limit their potential damage.

I like rsync, but I am not confident that it protects itself from an untrustworthy peer either. In some sense, all of these transfer tools could be replaced with a batch procedure or a pipeline that does "pack archive stream on sending side, transfer archive stream, unpack archive stream on receiving side". To mitigate the risks, you need a step in the middle like "filter or validate archive stream" which needs more understanding of what the invoking client _intended_ to do, so you can decide whether parts of the archive fall outside this scope.

An ancient OpenSSH vulnerability

Posted Jan 17, 2019 10:46 UTC (Thu) by job (guest, #670) [Link] (1 responses)

There are several different vulnerabilities involved, so there's a bit of both.

The first CVE is a clear validation failure, but the second is a bit more involved. It's hard to completely validate objects when the user asks for globs (which can be operating system specific) or other metadata (such as dates).

An ancient OpenSSH vulnerability

Posted Jan 17, 2019 22:24 UTC (Thu) by Pc5Y9sbv (guest, #41328) [Link]

I include filenames and filename-content mapping as parts of the transfer-of-metadata problem...

I think that file transfer based on globbing is inherently naive and unsafe. It's not a quality of implementation problem but a UX flaw where the user is too imprecise about their objectives. No validation can alleviate the trust problem with initiating transfer that can mix one origin's data and metadata into a space that may already contain conflicting data and metadata from other origins. Even if the transfer agent could prepare a summary of all changes and require user approval, it is probably unsafe in practice because the user would easily miss a dirty needle in the haystack.

A defensive user should narrowly scope transfers to specific target names or to independent hierarchies if it is impractical to enumerate each name as part of the transfer instructions. Then, a good quality transfer agent may be able to protect them against potential "escape" from this target space.

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 9:17 UTC (Wed) by grawity (subscriber, #80596) [Link]

PuTTY did this long ago: its pscp is just an SFTP client with an scp-like user interface.

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 11:38 UTC (Wed) by tao (subscriber, #17563) [Link] (1 responses)

I don't care about how it's implemented in the backend, as long as I can keep an scp command with the same syntax.

An ancient OpenSSH vulnerability

Posted Jan 17, 2019 10:29 UTC (Thu) by job (guest, #670) [Link]

As long as you don't use any options (few people do, as other tools are better suited), just train your fingers to type "rsync" instead. The basic syntax is similar.

An ancient OpenSSH vulnerability

Posted Jan 17, 2019 4:18 UTC (Thu) by dw (subscriber, #12017) [Link] (2 responses)

Unfortunately sftp is a horrible protocol for an entirely different set of reasons, not least:

- the hello message does not originate from the side of the connection who last acknowledged ssh channel setup, wasting a roundtrip

- the client immediately wastes another roundtrip figuring out the CWD after the hello

- the protocol requires 2 roundtrips to 'safely' open a file for writing

- the protocol provides no support for O_CREAT, so its impossible to write a file without an overwrite race

- the protocol wastes 2 roundtrips to finalize a transfer.

When operating recursively some of this is avoided, but most of it is sadly baked in. SFTP sucks

An ancient OpenSSH vulnerability

Posted Jan 17, 2019 17:47 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

> SFTP sucks

Does it suck relatively compared to scp/rcp or compared to your ideal vision, because comparing against actually existing deployed systems is often more useful than against frictionless spheres.

An ancient OpenSSH vulnerability

Posted Jan 17, 2019 17:51 UTC (Thu) by dw (subscriber, #12017) [Link]

It sucks relative to scp, where many of those roundtrips are fused. SFTP's main innovation is introducing stateful handles on either side of the connection, and the ability to mutate multiple files at once, but the default client doesn't use any of that, and the design was botched to start with.

An ancient OpenSSH vulnerability

Posted Jan 16, 2019 5:43 UTC (Wed) by eru (subscriber, #2753) [Link]

Isn't it a bit worrying that there has been no official release of OpenSSH that fixes these, even though the project was notified months ago? Lack of resources for a critical but taken-for-granted piece of infra? (as was with OpenSSL).

An ancient OpenSSH vulnerability

Posted Jan 23, 2019 7:21 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (2 responses)

At that point of time it would be mightily nice if someone took the time to reimplement the scp sftp userland commands over a subset of https (call that sftp/scp 3.0 if you like). The https ecosystem has grown so much in the past decades, it's several order of magnitudes safer (both protocol and implementation wise) than historical networking protocol alternatives.

An ancient OpenSSH vulnerability

Posted Jan 27, 2019 1:10 UTC (Sun) by flussence (guest, #85566) [Link] (1 responses)

It's several orders of magnitude more moving parts and mental working set. A “secure” HTTPS setup — by decree of its de-facto owners — requires no less than five cooperating parties: the client, the server, the CA, a gatekeeper (themselves) to decide who gets on the MITM invite list, and the CT loggers, because their gatekeeping is incompetent.

SSH is always a two-party conversation, generating certs for it takes 5 seconds and doesn't include a massive footgun of cipher options, and it doesn't ping half the globe to ask if it's okay to connect to your own server.

An ancient OpenSSH vulnerability

Posted Feb 21, 2019 10:18 UTC (Thu) by thestinger (guest, #91827) [Link]

HTTPS isn't strongly coupled to the CA-based browser-centric PKI ecosystem. It's a transport protocol. It's often used with other trust systems like hard-wired public key certificates in client applications or just different CAs such as organization-local ones.

SSH supports CAs in addition to the baseline Trust On First Use system most people experience. The baseline lacks any meaningful authentication for the first connection to a server unless a fingerprint / key is communicated out-of-band. It also does still include a lot of bad cipher options, and included more in the past. HTTPS only looks bad if you're talking about the legacy protocols, which aren't necessary in other contexts like they are for a browser. You can stick to TLS 1.2 / 1.3 only elsewhere.


Copyright © 2019, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds