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

51–60 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#51

Post by tedunangst »

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?

Does your cloud dashboard not tell you? Last resort, login on console and look at it.

Re: 35-year-old vulnerability discovered in scp

#52

Post by detaro »

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?

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.

Re: 35-year-old vulnerability discovered in scp

#53

Post by cat199 »

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…

> Which either means

or, it means the otherwise previously trusted server has been compromised, and the sshd has been replaced with a malicious one.

Re: 35-year-old vulnerability discovered in scp

#54

Post by jsiepkes »

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?

You can use SSHFP records in DNS. Clients like OpenSSH can be configured to retrieve and use those.

Re: 35-year-old vulnerability discovered in scp

#55

Post by eslaught »

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?

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.

Re: 35-year-old vulnerability discovered in scp

#56

Post by mikeash »

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…

If someone takes over my web server, this vulnerability means they can leverage that into taking over my personal computer? That’s catastrophic.

Re: 35-year-old vulnerability discovered in scp

#57

Post by vthriller »

jsiepkes wrote: post #54
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?

You can use SSHFP records in DNS. Clients like OpenSSH can be configured to retrieve and use those.

Aaand we've returned to discussions about hacks designed to make DNS at least somewhat trustful.

Re: 35-year-old vulnerability discovered in scp

#58

Post by runn1ng »

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…

The vulnerability is not that serious

From what I understand - if you scp any file from a remote server to your home directory, malicious remote server can copy anything else into your home directory without you knowing it, which can lead to remote code execution.

However, (1) the server needs to be malicious or compromised (or mitmd and you accept the new cert), (2) you need to copy into your home folder, not anywhere else, directory traversal is impossible

Re: 35-year-old vulnerability discovered in scp

#59

Post by mcv »

mikeash wrote: post #56
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…

If someone takes over my web server, this vulnerability means they can leverage that into taking over my personal computer? That’s catastrophic.

This sounds like the most plausible scenario in which this bug can cause havoc. Even if the web server is quickly restored to its original state, any user who happened to connect at the wrong time may still have a compromised PC.

And you may not even notice that the web server has been compromised until compromised PCs start acting up.

Re: 35-year-old vulnerability discovered in scp

#60

Post by jstanley »

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.

> I always blindly accept the key

Even from a host you use all the time and where know the key hasn't changed?

Post reply on HN