Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

35-year-old vulnerability discovered in scp

sintonen.fi

Post reply on HN
Print view View original

121–130 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#121

Post by jolmg »

teacpde wrote: post #113
jolmg wrote: post #95

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

> 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. The server description could be a subset of objects it writes to local.

Ok. For that, I think it would be apt for scp to somehow quote the filename when it contains a non-printable character, escaping the non-printable characters, thereby avoiding their interpretation as ANSI codes.

Re: 35-year-old vulnerability discovered in scp

#122

Post by teacpde »

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

Can someone explain how “employ ANSI codes to hide” works?

Re: 35-year-old vulnerability discovered in scp

#124

Post by freiheit »

teacpde wrote: post #122

> 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. Can someone explain how “employ ANSI codes to hide” works?

Your client asks for 1 file, the server comes back with 2 files (the 2nd one what you actually asked for), but the name of the first (tiny) file's name contains escape sequences that clear the line, move up a line, or otherwise obscure that the first file was sent.

Re: 35-year-old vulnerability discovered in scp

#125

Post by cosmotron »

winkywooster wrote: post #123

How is it a 35 year old vulnerability? ssh and friends have only been around for 25.

I believe the title is derived from the description of vulnerability #2:

> Due to the scp implementation being derived from 1983 rcp [1] ...

> [1] https://www.jeffgeerling.com/blog/brief-history-ssh-and-remo...

Re: 35-year-old vulnerability discovered in scp

#126

Post by walrus01 »

userbinator wrote: post #65

It's interesting that PSCP has this option: -unsafe allow server-side wildcards (DANGEROUS) and as explained in the doc ( https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter5.ht... ), "This is due to a fundamental insecurity in the old-style SCP protocol: the client sends the wildcard string (*.c) to the server, and the server sends back a sequence of file names that match the wildcard pattern. However, there is…

I strongly discourage anyone from using PuTTY, not for this reason, but for its weird and nonstandard handling of SSH keys.

The last time I tried to help someone get it set up on a windows PC, totally normal ssh2 rsa 2048 and 4096 bit public/private key pairs created with openssh had to be converted into some other weird format before they could get public/private key auth working.

Why the developers of putty felt they needed to deviate from standard ssh2-rsa pub/privkey formats is a mystery to me.

Re: 35-year-old vulnerability discovered in scp

#127

Post by rjbwork »

walrus01 wrote: post #126
userbinator wrote: post #65

It's interesting that PSCP has this option: -unsafe allow server-side wildcards (DANGEROUS) and as explained in the doc ( https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter5.ht... ), "This is due to a fundamental insecurity in the old-style SCP protocol: the client sends the wildcard string (*.c) to the server, and the server sends back a sequence of file names that match the wildcard pattern. However, there is…

I strongly discourage anyone from using PuTTY, not for this reason, but for its weird and nonstandard handling of SSH keys. The last time I tried to help someone get it set up on a windows PC, totally normal ssh2 rsa 2048 and 4096 bit public/private key pairs created with openssh had to be converted into some other weird format before they could get public/private key auth working. Why the developers of putty felt th…

It's quite easy. There are multiple tutorials on it. When you load up a key into putty the plain old key you're used to is sitting right there in a box in the app. Just copy.

Re: 35-year-old vulnerability discovered in scp

#128

Post by blattimwind »

jolmg wrote: post #119
rtkwe wrote: post #112

Earlier quoted context omitted.

At the very least the client could perform a check that the files it's receiving match the pattern it sent in the request by using a regular expression replacing * with an non-whitespace+forbidden character. It doesn't even check that if you request a single file like readme.txt that it receives a single file!

If you write: scp server:readme.txt . "readme.txt" is still shell code. Most shells will evaluate it to the string "readme.txt", but scp on the client should not make assumptions of the shell used on the server. If you write: scp server:'*.txt(oc[1,10])' . A server that's setup with zsh with extended globs is going to return the newest 10 .txt files. If scp is written with an expectation of basic globs, I imagine it…

Classic langsec failure.

Re: 35-year-old vulnerability discovered in scp

#129

Post by fulafel »

leni536 wrote: post #11

I quick test with strace and git shows that git doesn't use scp for handling ssh remotes. I suspect that git is hardened against similar attacks (a malicious server dropping files into .git/hooks would be worrisome).

Git recently had a malicious-server-rce bug, though not related.

Re: 35-year-old vulnerability discovered in scp

#130

Post by icedchai »

kurlberg wrote: post #37
jedberg wrote: post #24

Earlier quoted context omitted.

Right I get all that (I updated to clarify that I understand the attack is against your local home dir, but I assume you have one on the remote side). I just don’t understand the use case of scp’ing from an untrusted host.

Throughout the years my employers have reinstalled servers and consequently changed host keys. I believe many users just accept the new key without realizing what they might get themselves into. Ideally your organization should keep updated (public) host keys somewhere, say on some https-protected website so you can double check yourself. How common is this? (I mainly use ssh for interactive/tunneling use, but with a…

I've been using SSH since SSH-1 was released in 1995. I've never seen anyone verify a host key, ever!

Also, when I reinstall a server and keep the name, I preserve the keys from the original server.

Post reply on HN