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

71–80 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#71

Post by detaro »

amelius wrote: post #69
detaro wrote: post #52

Earlier quoted context omitted.

You can provide a pregenerated key to the instance during setup, e.g. using cloud-init. Or supply it with a way to report its key once it is generated. Or use out-of-band access, e.g. a host-provided console, to connect once and extract the key.

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

Why?/How does that relate to my answer? It'd make it harder to just accept a changed key instead of leaving the decision to the user, and would make use cases where the user doesn't want/need to authenticate the server harder (one can probably debate each scenario for that if the decision to not authenticate was "right"). Although I find it a bit weird there's not even an option to pass a host key to SSH instead of editing the KnownHosts file.

Re: 35-year-old vulnerability discovered in scp

#72

Post by CGvQpmp7kiLUTn »

jedberg wrote: 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…

This is precisely why i use firejail as a precaution against zero-days on ssh and other executable running from my Home account.

https://wiki.archlinux.org/index.php/firejail

Re: 35-year-old vulnerability discovered in scp

#73

Post by Ayesh »

h1d wrote: post #43
jedberg wrote: 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…

In my honest opinion, delegating the trust model down to the user to figure out which host key is trusted or not is the broken model. I always blindly accept the key because I have no way of knowing what is good or bad by looking at the prompt with random letters telling me it could be bad and in my life 100% of those alerts are false positives and I got used to accepting those alerts.

There is a DNS SSHFP record type that the history can publish the host keys.

I wrote about them some time back: https://ayesh.me/sshfp-verification

For servers without a domain pointed to it, I suppose you can still verify them by comparing the history key fingerprint by logging into said server with the console provided by server vendor.

Re: 35-year-old vulnerability discovered in scp

#74

Post by Insequent »

unilynx wrote: post #47
kurlberg wrote: post #37

Earlier quoted context omitted.

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…

Ideally they set up SSHFP dns records with the hostkey fingerprints Haven't yet encountered it in the wild though

Or they automatically distribute the host key fingerprints onto employees machines via some organization-wide internal method (ldap, orchestration/configuration management tool of the month, ssh_config pointing to a global known_hosts on a share, etc.).

Re: 35-year-old vulnerability discovered in scp

#75

Post by zurn »

jabl wrote: post #40
evgen wrote: post #6

Earlier quoted context omitted.

I believe you need to set scp_if_ssh = True in ansible.cfg for scp to ever be used, even if sftp is not available on the remote host.

Nowadays ansible uses a sort-of 'smart' method by default, where it first tries to use sftp, and if that fails, falls back to scp. See https://docs.ansible.com/ansible/latest/plugins/connection/s...

So if the server is compromised, it can fail the sftp in a suitable way?

But its another matter if ansible's scp client is vulnerable to this.

Re: 35-year-old vulnerability discovered in scp

#76

Post by athenot »

jedberg wrote: 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…

> Edit: To clarify, I understand why you’d want to fix this, for a good depth of defense. I’m just saying I don’t feel any urgency in fixing this.

If you exclusively SCP to servers you control, this is admittedly a low priority issue.

However some companies use SCP extensively as a way to exchange data files (as an upgrade from using FTP, and out of frustration from dealing with implicit/explicit FTPS modes). Healthcare and finance come to mind for those use cases.

Re: 35-year-old vulnerability discovered in scp

#77

Post by da_chicken »

jakobegger wrote: post #16
korpiq wrote: post #8

Earlier quoted context omitted.

I read it as being MitM and manipulating target (final, originally intended server) directories and files only, and in addition to spoof output to client to hide the fact it's doing so. In that case it does not matter where you run the client. What makes MitMs possible is that checking fingerprint of new host is left to user. Instead we should have processes to automatically 1. acquire via other means and add fingerp…

There is already a solution to this problem, which is host key certificates. All you need to do is configure your SSH client to accept only host keys signed by your CA. However, setting that up is complicated. You need a lot of knowledge to set that up securely. On the other hand, manual verification of host keys is trivial -- anybody can compare a short string of characters.

Your solution is that a system you trust is impossible to compromise? That seems unreasonably optimistic.

Re: 35-year-old vulnerability discovered in scp

#78

Post by gruez »

Ayesh wrote: post #73
h1d wrote: post #43

Earlier quoted context omitted.

In my honest opinion, delegating the trust model down to the user to figure out which host key is trusted or not is the broken model. I always blindly accept the key because I have no way of knowing what is good or bad by looking at the prompt with random letters telling me it could be bad and in my life 100% of those alerts are false positives and I got used to accepting those alerts.

There is a DNS SSHFP record type that the history can publish the host keys. I wrote about them some time back: https://ayesh.me/sshfp-verification For servers without a domain pointed to it, I suppose you can still verify them by comparing the history key fingerprint by logging into said server with the console provided by server vendor.

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

Re: 35-year-old vulnerability discovered in scp

#79

Post by nothrabannosir »

amelius wrote: post #69
detaro wrote: post #52

Earlier quoted context omitted.

You can provide a pregenerated key to the instance during setup, e.g. using cloud-init. Or supply it with a way to report its key once it is generated. Or use out-of-band access, e.g. a host-provided console, to connect once and extract the key.

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 I think it’s inescapable: SSH was not made for humans.

(This is purely a client issue, by the way. But at the end of the day: does that matter for anyone?)

(Edit: when this comes up people often mention key based auth. Unfortunately, that relies on nobody else having your public key. You can find mine anywhere, it used to be available through the GitHub api , even. It won’t let the attacker connect to the original server but they can definitely impersonate it. Perhaps get your key agent forwarded, and continue. Not great.)

Re: 35-year-old vulnerability discovered in scp

#80

Post by nathan_long »

XCabbage wrote: post #61
jedberg wrote: 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…

What you're missing is very simple: downloading files from a server need not imply that you trust the server even slightly. That's true whether you're downloading them via HTTPS (e.g. to view this web page) or via SCP. Many of us have jobs in which we typically only use SSH to connect to servers that we trust and control. But that assumption is no more baked into the security model of SSH than it is into the security…

> The argument that "you trusted this server enough to connect to it and download a file, therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false in both cases.

Great point. Also, imagine that you control the server and you know that it was compromised. Surely you want to be able to download logs and other files from it for inspection without having your own machine compromised.

Post reply on HN