Bug 1665785 (CVE-2018-20685) - CVE-2018-20685 openssh: scp client improper directory name validation
Summary: CVE-2018-20685 openssh: scp client improper directory name validation
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2018-20685
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1665786 1666574 1666575
Blocks: 1665788
TreeView+ depends on / blocked
 
Reported: 2019-01-14 02:42 UTC by Sam Fowler
Modified: 2020-04-24 03:41 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-06 00:51:40 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3702 None None None 2019-11-05 22:06:23 UTC

Description Sam Fowler 2019-01-14 02:42:10 UTC
In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to bypass intended access restrictions via the filename of . or an empty filename.


Upstream Patch:

https://github.com/openssh/openssh-portable/commit/6010c030
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/scp.c.diff?r1=1.197&r2=1.198&f=h

Comment 1 Sam Fowler 2019-01-14 02:42:46 UTC
Created openssh tracking bugs for this issue:

Affects: fedora-all [bug 1665786]

Comment 2 Tomas Hoger 2019-01-14 08:50:22 UTC
External References:

https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt

Comment 4 Huzaifa S. Sidhpurwala 2019-01-16 05:04:20 UTC
Analysis:

This is a flaw in the scp client (/usr/bin/scp) shipped as a part of openssh-clients package. The flaw essentially allows a malicious scp server to modify the permissions of the target directory by using certain ANSI characters (empty ("D0777 0 \n") or dot ("D0777 0 .\n") directory name as per the upstream advisory).

To trigger this flaw, the scp client needs to either connect to a malicious scp server or connect to a MITM scp server. Connecting to a MITM server will require the client to accept the new host key, which essentially implies that either the scp server (which the client previously connected to) has changed or there is a possible MITM attempt, both of which should be investigated by the system administrator before going ahead with the connection.

Also note that, since this is a flaw in the scp utility, the SSH client is not affected.

Comment 5 Huzaifa S. Sidhpurwala 2019-01-16 05:06:42 UTC
Statement:

This issue affects the scp client shipped with openssh. The SSH protocol or the SSH client is not affected. For more detailed analysis please refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1665785#c4

Comment 8 Huzaifa S. Sidhpurwala 2019-07-23 03:22:09 UTC
Mitigation:

This issue only affects the users of scp binary which is a part of openssh-clients package. Other usage of SSH protocol or other ssh clients is not affected. Administrators can uninstall openssh-clients for additional protection against accidental usage of this binary. Removing the openssh-clients package will make binaries like scp and ssh etc unavailable on that system.

Note: To exploit this flaw, the victim needs to connect to a malicious SSH server or MITM (Man-in-the-middle) the scp connection, both of which can be detected by the system administrator via a change in the host key of the SSH server. Further, if connections via scp are made to only trusted SSH servers, then those use-cases are not vulnerable to this security flaw.

Comment 10 errata-xmlrpc 2019-11-05 22:06:22 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2019:3702 https://access.redhat.com/errata/RHSA-2019:3702

Comment 11 Product Security DevOps Team 2019-11-06 00:51:40 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2018-20685


Note You need to log in before you can comment on or make changes to this bug.