Live data from Hacker News

35-year-old vulnerability discovered in scp

sintonen.fi

151–158 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#151
post #148

Earlier quoted context omitted.

Your condescension is noted. The host key fingerprint does matter. That's the host's public key. The host also has a private key. Without that private key, Bob can't pretend to be Eve. You are correct that when connecting to Bob, if his public key doesn't match Eve's expected key, it will prompt the user to cancel the connection. You argue: "It will only require the public key (which is public) to impersonate the ser…

Eve is the bad guy, Bob is the intended party. Bob is not stealing keys, Eve is. Well, not "stealing", just obtaining public keys. The attack is on Alice, who thinks she's connecting to Bob, but is actually connecting to Eve. This is on initial connect, and assuming Alice doesn't check the host fingerprint ( which nobody does ; that's the crux of my point). This nomenclature is the convention when discussing cryptogr…

Okay, swap Bob and Eve then.

Re: 35-year-old vulnerability discovered in scp

#153
post #151

Earlier quoted context omitted.

Eve is the bad guy, Bob is the intended party. Bob is not stealing keys, Eve is. Well, not "stealing", just obtaining public keys. The attack is on Alice, who thinks she's connecting to Bob, but is actually connecting to Eve. This is on initial connect, and assuming Alice doesn't check the host fingerprint ( which nobody does ; that's the crux of my point). This nomenclature is the convention when discussing cryptogr…

Okay, swap Bob and Eve then.

Okay. "The attack is on Alice, who thinks she's connecting to Eve, but is actually connecting to Bob. Assuming Alice doesn't check the host fingerprint (which nobody does), the attack succeeds."

You're fundamentally misunderstanding the argument about which key is being copied. It's Alice's public key that's copied. The fake server generates its own public and private keys and nobody notices that it doesn't match the real server. The user won't be "prompted to cancel" when this is their first time connecting.

authorized_hosts, as typically used, prevents an imposter from showing up later. It does absolutely nothing to prevent an imposter that's there from the start.

Re: 35-year-old vulnerability discovered in scp

#154
post #10

I think I'm missing something. Step one is getting you to use a compromised server. Which either means the server your home directory is on is compromised (I’m assuming you have a login on the box, separate from your local home dir), in which case scp is the least of your worries, or they get you to bounce through a MITM server, in which case you have to accept an incorrect host key. If you're accepting incorrect hos…

reminds me of this raymond chen post https://blogs.msdn.microsoft.com/oldnewthing/20121207-00/?p=... with the quote "It's not really a vulnerability that you can do anything you want once you pwn the machine."

This is getting [partial] control of every machine that merely downloads a file from the one you took over.

Re: 35-year-old vulnerability discovered in scp

#155

> Man-in-the-Middle attack does require the victim to accept the wrong host fingerprint. This should be a WONTFIX. The idea that it could be not only a man-in-the-middle attack but simply a "malicious scp server" is completely ridiculous. No secure login or transfer method can protect you from the actions of a malicious server, which could be anything. If I have the root privs to install malicious software on the ser…

> No [...] transfer method can protect you from the actions of a malicious server

Try applying that logic to a web browser. Oh, just do whatever the server says and overwrite whatever files it wants?

Re: 35-year-old vulnerability discovered in scp

#156
post #118

Earlier quoted context omitted.

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.

`ssh-keyscan -t rsa github.com | ssh-keygen -lf -` gives you the fingerprint for github.com. Save this key, and reuse it everywhere before connecting to github. Now the issue of being MITM'd is once again only an issue with your very first connection, which is done via ssh-keyscan. As for your other servers, you should only check the host key once for any of them, and then save it. And that's only if they are owned b…

I currently check fingerprints on first connection and then save them. They're available for most servers, including github and other git providers. I think I've only had to connect to one server without knowing the fingerprint in advance in the last couple of years.

Looks to me like the fingerprint-checking process has to be manual if you can't choose the server certificate.

Re: 35-year-old vulnerability discovered in scp

#157
post #41
post #21

Earlier quoted context omitted.

The server could also drop a "ls" file with execution rights in current directory. If "." is in your path before /usr/bin (I have already encounter that), it may be called as soon as you type ls (generally just after the scp).

Sure, it can also drop filenames starting with a dash, filenames with spaces/newlines in it and all sorts of stuff. These can cause all kind of havoc in poorly written scripts. Having "." in your path is an obvious misconfiguration too.

Having a trailing : at the end of the PATH is the same as :. and occurs quite often.

Re: 35-year-old vulnerability discovered in scp

#158
post #97

> Man-in-the-Middle attack does require the victim to accept the wrong host fingerprint. This should be a WONTFIX. The idea that it could be not only a man-in-the-middle attack but simply a "malicious scp server" is completely ridiculous. No secure login or transfer method can protect you from the actions of a malicious server, which could be anything. If I have the root privs to install malicious software on the ser…

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.

[deleted]
Post reply on HN