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

141–150 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#141

Post by jolmg »

blattimwind wrote: post #138
jolmg wrote: post #131

Earlier quoted context omitted.

Can you expand on that? I can't tell if you're in favor or against a change.

Well the language scp uses for selecting files is turing complete and relies on state unavailable to the client therefore it is impossible in the general case for the client to check whether a given file sent by the server was actually requested by itself. That's the langsec failure here. The "correct" (in any case more sane) approach would be to use a stateless, easily recognizable language for specifying files (e.g…

And that's what I meant by saying that I couldn't see what else to do without sacrificing usability. Whatever that language you propose would be, if it doesn't allow use of state from the server, then it's pointless. You may as well use the local shell in scp's invocation.

Re: 35-year-old vulnerability discovered in scp

#142

Post by miohtama »

JohnFen wrote: post #104
XCabbage wrote: post #85

Earlier quoted context omitted.

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…

> It's entirely possible to use Javascript to place malware (such as installing a binary executable) and do other assorted nastiness on a target

This sounds interesting. Can you kindly link an example for this technique?

Re: 35-year-old vulnerability discovered in scp

#143

Post by Cpoll »

JohnFen wrote: post #104
XCabbage wrote: post #85

Earlier quoted context omitted.

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…

But if you want to go that far, it's entirely possible with Javascript disabled. Not every browser bug is a JS engine bug.

Your best bet (not guaranteed) is reading the html as plain text, not rendering any images, etc.

Re: 35-year-old vulnerability discovered in scp

#144

Post by Cpoll »

jedberg wrote: post #26
eof wrote: post #23

Earlier quoted context omitted.

> Step one is getting you to use a compromised server. This is not at all uncommon. Consider I need to send you files, either once or on a batch schedule. You say, "give me your key, you can drop them on this server" I feel safe since I am just writing files to your server, not expecting you are going to drop arbitrary code that will run next time I open my terminal.

Unless I’m mistaken you’d still be safe. The vuln would only work if you were pulling files from an untrusted host, not pushing to it. But if I wanted to share files with you, I’d just put them on the web, unless we already have a relationship where you can ssh somewhere that I have access to. In which case I assume we’re trusted or you’ve at least verified the host key.

It's the reverse, but it's almost the same. "Give me your key, and then take these files from my server."

I feel safe, because I think I'm going to cat a text file, not execute it.

Re: 35-year-old vulnerability discovered in scp

#145

Post by Bartweiss »

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.

Nicely put.

This feels like yet another variant of the same confusion we see around web browsing, with people saying "oh, if you don't want a virus don't go to sketchy sites". Agreeing to receive HTML or even run unfamiliar Javascript in a browser shouldn't be equated with trusting that website to run anything outside the sandbox, and in a world where ads on major sites are frequently resold through a half-dozen shoddy networks it's an important distinction.

Re: 35-year-old vulnerability discovered in scp

#146

Post by kakarot »

dancek wrote: post #118
kakarot wrote: post #110

Earlier quoted context omitted.

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

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 by a third-party, like a shared server. If your provider routinely cycles host keys, get a new provider who actually cares about security.

If these servers are owned by your employer, then your employer needs better security practices and, failing a certificate authority, should provide you with the necessary host fingerprints before you ever connect to a box.

Re: 35-year-old vulnerability discovered in scp

#148

Post by fwip »

nothrabannosir wrote: post #139
fwip wrote: post #134

Earlier quoted context omitted.

I'm not sure you know how public/private keys work.

This reply is tragicomically ironic :( See it like this: The bug is in the verification of the host , not the user. Eve can intercept a connection from Alice to Bob. It can "pretend" to be Bob, but it can't MITM (aka "proxy") because it won't be able to auth with Bob. However, auth depends on the server encrypting a message with Alice's public key, which everyone has ( https://github.com/torvalds.keys !), including E…

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 server." The key piece here you are missing is that if Bob steals Eve's public key, he won't have a matching private key, and authentication will fail.

If you don't think the private keys are important, go edit them on your server, and see how SSH'ing in goes for you.

Re: 35-year-old vulnerability discovered in scp

#149

Post by kazinator »

Aeolun wrote: post #98
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…

Expansion of privileges. If a malicious actor is already in your network, but doesn’t have domain admin right yet for example, taking control of all the machines that connect to a server they do have control over would be helpful in a variety of ways.

> If a malicious actor is already in your network ...

Then you're talking about a man-in-the-middle attack, which I acknowledge as a problem.

I don't agree that fixing bugs which date back to the completely insecure rcp program are the key to solving man-in-the-middle attacks in the SSH suite.

If you have to put in defenses at that level, you've already lost; the goal must be to eliminate or minimize the threat of a MITM attack on the authentication system.

This nonsense is analogous to putting a layer of Pig Latin and ROT-13 into the protocol in case the attacker breaks the AES cipher.

Re: 35-year-old vulnerability discovered in scp

#150

Post by nothrabannosir »

fwip wrote: post #148
nothrabannosir wrote: post #139

Earlier quoted context omitted.

This reply is tragicomically ironic :( See it like this: The bug is in the verification of the host , not the user. Eve can intercept a connection from Alice to Bob. It can "pretend" to be Bob, but it can't MITM (aka "proxy") because it won't be able to auth with Bob. However, auth depends on the server encrypting a message with Alice's public key, which everyone has ( https://github.com/torvalds.keys !), including E…

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 cryptographic attacks: https://en.wikipedia.org/wiki/Alice_and_Bob

I'm going to stop discussing this in this thread, but feel free to contact me (info in profile). I promise to engage, in good faith, and if you do end up convincing me, I'll post an update here.

Best wishes.

Post reply on HN