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

111–120 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#111

Post by aaronmdjones »

nothrabannosir wrote: post #79
amelius wrote: post #69

Earlier quoted context omitted.

Ok, but shouldn't ssh require the user to type in the entire key then, rather than to type yes/no?

Yes, the SSH flow is completely broken and, therefore, in reality only really protects against passive snooping. I have never met a real human, in real life, who ever checked the host key on first connect. For what it’s worth: The way to solve this is require the host key fingerprint as an argument to the ssh command, along with host and user. This would force people to look it up. This is not a popular opinion, but…

No, the way to solve this is to use client public key authentication. Then a successful MITM will require the client's private key too.

Re: 35-year-old vulnerability discovered in scp

#112

Post by rtkwe »

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…

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!

Re: 35-year-old vulnerability discovered in scp

#113

Post by teacpde »

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.

Re: 35-year-old vulnerability discovered in scp

#115

Post by gruez »

xoa wrote: post #89
gruez wrote: post #78

Earlier quoted context omitted.

And how do you trust that the dns record hasn’t been tampered with? DNSSEC?

The article mentions DNSSEC, but is that a limiting factor in this case? If you are connecting to a server you specifically have out of band access to then just use pre-shared keys like normal and none of this is relevant. If you don't and DNS is compromised then you're depending on DNS anyway right? At that point getting the host pubkey from DNS too doesn't seem like it hurts anything and it could still defend again…

The threat model SSHFP protects against from is some adversary that's in the middle of you and the server (not close to you or the server). It does nothing against an evil ISP or evil AP, which FTPS (with CA signed certificates) does protect you against.

Re: 35-year-old vulnerability discovered in scp

#118

Post by dancek »

kakarot wrote: post #110
dancek wrote: post #97

Earlier quoted context omitted.

Some people only check a couple of bytes in the beginning and end of the host fingerprint. I've done that. It's not ridiculous to prevent attack vectors that depend on common behavior, even if it's strictly speaking the user's fault.

You should not be checking the host fingerprint at all. 1. Use `VisualHostKey=yes` in your ssh config. Learn the randomart image for your server. Don't try to compare two long random strings directly, that's not a job for humans. 2. Use an offline SSH certificate authority to generate SSH certificates, bypassing the need for a host fingerprint check altogether. If you can trust your offline CA, you don't need to trus…

Sounds good in theory. Now, say I want to use github over ssh, how do I check if the randomart image is correct? (Getting my configs from github tends to be the first thing I do on a new machine.)

The CA approach is probably good if you control the servers you use. Right now I connect to about 5-7 ssh servers on a regular basis, and I don't have (full) control over any one of them.

Re: 35-year-old vulnerability discovered in scp

#119

Post by jolmg »

rtkwe wrote: post #112
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…

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 would try to match the files that have a character-by-character literal extension of ".txt(oc[1,10])". That means no file is ever going to match. You could say, "well, add recognition of zsh extended globs". Ignoring how complicated that really is because there are glob options that allow you to embed arbitrary zsh code, you're limiting the implementation of scp to work with only particular shells. scp should not be a barrier to me implementing my own shell, with it's own syntax and using it transparently. The current scp doesn't care about what shells you use where. It makes little to no assumptions of the tools you use, and that's cool.

Re: 35-year-old vulnerability discovered in scp

#120

Post by nothrabannosir »

aaronmdjones wrote: post #111
nothrabannosir wrote: post #79

Earlier quoted context omitted.

Yes, the SSH flow is completely broken and, therefore, in reality only really protects against passive snooping. I have never met a real human, in real life, who ever checked the host key on first connect. For what it’s worth: The way to solve this is require the host key fingerprint as an argument to the ssh command, along with host and user. This would force people to look it up. This is not a popular opinion, but…

No, the way to solve this is to use client public key authentication. Then a successful MITM will require the client's private key too.

No, it will only require the public key (which is public) to impersonate the server. It won’t be a MITM but it’s still bad; see e.g. the bug in this very article, or if (god forbid) you’ve set up agent forwarding. Or if you do e.g. a git pull from github on a fresh comp, it can serve you bad code.

Asymmetric key is not a solution to the problem of users blindly trusting hosts without checking the fingerprint. It’s a UI problem.

Every time I bring this up it gets shot down (e.g. now -3 votes), and every time I wait for someone to put forward an actual counter argument. Unfortunately, no luck.

SSH is broken and it needs fixing.

Post reply on HN