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

81–90 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#81

Post by tombrossman »

Kovah wrote: post #50
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.

Could someone elaborate on how to find out the correct key of a host that was recently setup, like a new Digitalocean instance? Is there even a method?

Yes, it is probably in /etc/ssh/. What type of key depends on your distro and version, but here is a helpful explanation for Ubuntu: https://askubuntu.com/a/76388

Re: 35-year-old vulnerability discovered in scp

#82

Post by zurn »

athenot wrote: post #76
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). Healthc…

When someone breaks into your servers, it's still kind of bad. Consider, for one, that the admins risk their laptops getting pwned when getting logs from said boxes. Easy to get from "one compromised server" to bigger problems this way.

Re: 35-year-old vulnerability discovered in scp

#83

Post by peterwwillis »

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…

A lot of what we do implies trust.

We trust the browser not to have bugs, the TLS protocol to remain secure against attack, every CA to not grant MITM power to a state actor, the TCP/IP stack not to be remotely exploitable. Much of the world downloads unsigned code and exectues it locally, whether it be a Go client, an interpreted library code dependency, or "curl | bash". Windows has warnings before you run unsigned code, but most people run it anyway.

We trust a lot of things, and maybe we shouldn't. The important thing, to me, is how informed I am about the trust I'm giving, and to whom, and what risks I'm willing to take.

I use scp infrequently and on machines that I control, so that's a level of risk I'm comfortable with. But if the bug had been in curl, my blood pressure might be slightly higher.

Re: 35-year-old vulnerability discovered in scp

#84

Post by VRay »

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…

> therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false

Unless you run your browser without an ad blocker

Re: 35-year-old vulnerability discovered in scp

#85

Post by XCabbage »

VRay wrote: post #84
XCabbage wrote: post #61

Earlier quoted context omitted.

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…

> therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false Unless you run your browser without an ad blocker

Yeah, I thought that sort of quip might come along. ;)

On the one hand, you have a real point. On the other, JavaScript running in my browser has significantly less power to do anything bad to me than arbitrary executable programs running directly in my OS do.

Re: 35-year-old vulnerability discovered in scp

#86

Post by toyg »

nathan_long wrote: post #80
XCabbage wrote: post #61

Earlier quoted context omitted.

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

> Surely you want to be able to download logs

Uhm, nope: you want to shut it down and perform forensics on the disk. Once it's rooted, I wouldn't touch it with a barge pole.

Re: 35-year-old vulnerability discovered in scp

#87

Post by toyg »

jstanley wrote: post #60
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.

> I always blindly accept the key Even from a host you use all the time and where know the key hasn't changed?

"Frack knows what all dem Gilfoyles do all the time. I have shit to do."

Re: 35-year-old vulnerability discovered in scp

#88

Post by XCabbage »

toyg wrote: post #86
nathan_long wrote: post #80

Earlier quoted context omitted.

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

> Surely you want to be able to download logs Uhm, nope: you want to shut it down and perform forensics on the disk. Once it's rooted, I wouldn't touch it with a barge pole.

I've been a web developer for over 5 years and never once worked somewhere where I'd have any imaginable way of physically accessing the disk of a server. Everything's been cloud-based. I don't know the exact ratios, but I'd expect my experience not to be unusual.

Re: 35-year-old vulnerability discovered in scp

#89

Post by xoa »

gruez wrote: post #78
Ayesh wrote: post #73

Earlier quoted context omitted.

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?

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 against MITM if the chain from you to DNS is different then you to the server (not uncommon I'd think, since a lot of people are either using their local resolver, using their ISP's at 1 hop, or using someone distributed like Cloudflare who are also minimal hops). Of course authentic secure DNS is really important anyway, and worth working on. Beyond DNSSEC there is also DNS over HTTPS. And just using shared keys and nothing else, no option to even accept if it changes, is best of all. But if that doesn't work for whatever reason having it in DNS doesn't seem like an awful idea, anymore then Let's Encrypt depending on DNS does right?

Re: 35-year-old vulnerability discovered in scp

#90

Post by detaro »

XCabbage wrote: post #88
toyg wrote: post #86

Earlier quoted context omitted.

> Surely you want to be able to download logs Uhm, nope: you want to shut it down and perform forensics on the disk. Once it's rooted, I wouldn't touch it with a barge pole.

I've been a web developer for over 5 years and never once worked somewhere where I'd have any imaginable way of physically accessing the disk of a server. Everything's been cloud-based. I don't know the exact ratios, but I'd expect my experience not to be unusual.

You can't physically access the disk, but you often can download a snapshot or disk image, which is created at the hypervisor level.
Post reply on HN