[SOLVED] Mitigate CVE-2020-15778

Tharbad · 2020-09-30 10:06:35

Hi all,

It seems there is a new vulnerability with scp: https://cve.mitre.org/cgi-bin/cvename.c … 2020-15778
I would like to disable it. There is also a note about it in the wiki: https://wiki.archlinux.org/index.php/SC … ocol_(SCP) but nothing about disabling it.
So how do I disable it? Delete it? Link it to /bin/false (saw it somewhere)?
(I know I also need to add a pacman hook for future updates)

Thanks

Last edited by Tharbad (2020-10-08 06:09:23)

graysky · 2020-09-30 11:07:24

You can delete it and use a NoExtract within /etc/pacman.conf if you wish.

Zod · 2020-09-30 11:26:11

It is a utility, you could always not use it?

From the folks at Openssh..

The scp command is a historical protocol (called rcp) which relies upon that style of argument passing and encounters expansion problems. It has proven very difficult to add "security" to the scp model. All attempts to "detect" and "prevent" anomalous argument transfers stand a great chance of breaking existing workflows. Yes, we recognize it the situation sucks. But we don't want to break the easy patterns people use scp for, until there is a commonplace replacement. People should use rsync or something else instead if they are concerned.

Edit: I guess it would be helpful if we understood what your concern is.
Are you operating a publicly accessible FTP server?
Are you operating a server and are concerned that users might use the vulnerability to do harm?

Last edited by Zod (2020-09-30 11:51:55)

loqs · 2020-09-30 13:24:30

CVE-2020-15778 does not appear to me to allow a user to do anything they could not do by logging in with ssh.

seth · 2020-09-30 17:11:36

https://github.com/cpandya2909/CVE-2020 … -scenarios is a bit fringe, because it either assumes ssh being locally bloked but scp allowed ('key) or an attack on the local FS to attack the server
It's certainly a bug that can cause nasty and unexpected behavior (if you're into shell command filenames - with backticks…) but nothing I'd lose a sleepless night over.

But yeah, delete and NoExtract it, nobody™ uses it anymore anyway.

loqs · 2020-09-30 20:20:30

My understanding is scp remote connects using ssh to local sshd which executes local scp.
So if sshd is not not running or the remote scp can not auth to local sshd then scp remote would fail.
If the scp binary is missing the attacker could use ssh login.
The default Arch pam sshd stack uses remote-login which includes login which includes pam_shells.so. So would the attacker not need a valid account with a valid login shell to perform the attack via scp or ssh?

Last edited by loqs (2020-09-30 20:21:19)

seth · 2020-10-01 06:28:25

The required setup is rather very specific.
You can force a certain server command to be executed instead of $SHELL and you can utilize this to effectively enforce a certain client command (see links) - which btw. seems überwonky in and by itself, assuming I control the local sshd.

If somebody has really implemented the above, please just enforce and use sftp.

https://serverfault.com/questions/85230 … o-scp-only
https://github.com/scponly/scponly

Tharbad · 2020-10-08 06:09:07

Thank you all for the clearifications.

Arch Linux

#1 2020-09-30 10:06:35

[SOLVED] Mitigate CVE-2020-15778

#2 2020-09-30 11:07:24

Re: [SOLVED] Mitigate CVE-2020-15778

#3 2020-09-30 11:26:11

Re: [SOLVED] Mitigate CVE-2020-15778

#4 2020-09-30 13:24:30

Re: [SOLVED] Mitigate CVE-2020-15778

#5 2020-09-30 17:11:36

Re: [SOLVED] Mitigate CVE-2020-15778

#6 2020-09-30 20:20:30

Re: [SOLVED] Mitigate CVE-2020-15778

#7 2020-10-01 06:28:25

Re: [SOLVED] Mitigate CVE-2020-15778

#8 2020-10-08 06:09:07

Re: [SOLVED] Mitigate CVE-2020-15778

Board footer