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

101–110 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#101

Post by shawnz »

jedberg wrote: post #24
rocqua wrote: post #20

Earlier quoted context omitted.

> the server your home directory is on is compromised The attack presumes your home directory is client side, and you use SCP to connect to any kind of server, whilst ~ is the client side open directory. Thus, any server you might SCP to could write to your local home dir. In university, I did this with compute clusters, servers of my association and other servers. This breaks the SCP security model because it means…

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.

> I just don’t understand the use case of scp’ing from an untrusted host.

What? Why would it even be an expectation that the host ought to be trusted? Would you say that about FTP, or HTTP or any other file transfer protocol? What's special about SCP?

Re: 35-year-old vulnerability discovered in scp

#102

Post by cosmie »

zwp wrote: post #45
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.

In the B2B world there is a perhaps surprising amount of ad hoc data transfer (transactions, statements) between separate entities using scp/sftp from a cron'ed ksh script written by a junior sysadmin 8 years ago. Throw a Tectia server in the DMZ, fix the firewall, manage some keys (never change them) and you're good to go! Data at rest security via Zip or PGP for the ambitious. Occasionally a big enough entity will…

> Occasionally a big enough entity will mandate "everyone will use our data xfer spec" (and it's typically some gnarly XML-infested SOAPy animal).

In which case, you leave your CSV-over-scp or CSV-over-FTP in place, and duct tape on another layer that handles the new data transfer spec. That way you can leave the 8 year old process itself alone and let it keep creaking away, silently chugging away as it slowly fades into the twilight of "important but forgotten" systems running on autopilot throughout the years.

It reminds me of how places like Rome still have sewers from the days of Ancient Rome in operation. Rather than replace them outright, they were just connected them to the newer sewer system to divert the waste to treatment plants instead of directly to water sources. And they'll keep on going, only being updated when absolutely necessary to warrant it.

Re: 35-year-old vulnerability discovered in scp

#103

Post by [deleted] »

dancek wrote: post #97
kazinator wrote: post #94

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

Re: 35-year-old vulnerability discovered in scp

#104

Post by JohnFen »

XCabbage wrote: post #85
VRay wrote: post #84

Earlier quoted context omitted.

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

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

I think that depends on what you mean by "significantly less power". It's entirely possible to use Javascript to place malware (such as installing a binary executable) and do other assorted nastiness on a target machine. If the target machine is properly secured, it's still possible, it just requires more effort.

This is the primary reason why I do not allow Javascript to run on my machines by default. If I'm at a site that I trust and I have no alternative to using, and the JS in question is essential, then I'll allow just the specific piece of JS to run. Otherwise, it's not happening.

Re: 35-year-old vulnerability discovered in scp

#105

Post by spenczar5 »

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.

Every cloud provider out there would help you get an image of the disk if you told them it was due to a security breach.

Re: 35-year-old vulnerability discovered in scp

#106

Post by spenczar5 »

XCabbage wrote: post #85
VRay wrote: post #84

Earlier quoted context omitted.

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

These days, so much happens in browsers (banking, medical records, social communications) that it's hard for me to imagine a more dangerous place to give up execution. What sort of things are you thinking of that scare you more on the OS?

Re: 35-year-old vulnerability discovered in scp

#107

Post by tptacek »

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…

Authentic secure DNS is in fact not important, and is not worth working on. I think the lengths you had to go to just now to establish some kind of marginal value for SSHFP is a good illustration of why. And that's because we've designed protocols for the past 20 years to assume the DNS is insecure. SSH, in particular, has "don't trust DNS" baked into its DNA; it's a response to the old Unix r-commands, which did trust DNS.

Re: 35-year-old vulnerability discovered in scp

#108

Post by kakarot »

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 anyone is curious, the way to prevent this is:

scp_if_ssh = false

Re: 35-year-old vulnerability discovered in scp

#109

Post by __david__ »

eslaught wrote: post #55
Kovah wrote: post #50

Earlier quoted context omitted.

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?

It gets printed to the console by default when you run cloud-init, and e.g. in AWS you can retrieve the console logs with an API call and grep for what you want. I've got a script sitting around here somewhere which does this... Not necessarily in a state that's easy to reuse, of course.

It doesn't work if your cloud init prints too much. AWS only holds a certain amount and the so the API call will truncate the output and lose the key (it shows you the tail and not the head of I remember correctly). Our organization has this problem (we run puppet in cloud init which spews like crazy).

I did notice recently that cloud init has an option to hot a web hook when it is complete and they have options in there to add the host key to the POST. But I wonder how to make a web hook that would be immune to spoofing…

Re: 35-year-old vulnerability discovered in scp

#110

Post by kakarot »

dancek wrote: post #97
kazinator wrote: post #94

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

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 trust your server's host key at all. Either they have a valid certificate or they don't. Your SSH client won't even ask you if you trust the server.

It's one thing to access a compromised server, but you should NEVER be exposed to MITM attacks with proper SSH usage, except for your very first connection on a brand-spanking new server when you drop your SSH host certificates (ideally in an automated fashion which can be deployed immediately after spinning up your box).

Post reply on HN