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

61–70 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#61

Post by XCabbage »

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 model of HTTPS. 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.

Re: 35-year-old vulnerability discovered in scp

#62

Post by dmurray »

joelthelion wrote: post #12
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…

I think what it's saying is that in the event you connect to a malicious server, that server is able to do more damage to the client than it ought to. Should be fixed, but clearly not the worse vulnerability ever.

That's the definition of, for example, all browser security issues.

Re: 35-year-old vulnerability discovered in scp

#63

Post by etatoby »

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…

I always go CSV-over-SCP called from a crontab, over anything more complicated like SOAP, whenever I have any say. I try to strengthen both accounts, for instance having the target account only accept SCP connections, but still this kind of bug could be exploited maliciously to jump from one server (or company!) to another.

Re: 35-year-old vulnerability discovered in scp

#64

Post by bryanrasmussen »

bryanrasmussen wrote: post #32
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…

reminds me of this raymond chen post https://blogs.msdn.microsoft.com/oldnewthing/20121207-00/?p=... with the quote "It's not really a vulnerability that you can do anything you want once you pwn the machine."

of course, if Windows used a capability based security model then it would still be a vulnerability that you could do anything you want once you pwn the machine.

Re: 35-year-old vulnerability discovered in scp

#65

Post by userbinator »

It's interesting that PSCP has this option:

    -unsafe   allow server-side wildcards (DANGEROUS)
and as explained in the doc (https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter5.ht...),

"This is due to a fundamental insecurity in the old-style SCP protocol: the client sends the wildcard string (*.c) to the server, and the server sends back a sequence of file names that match the wildcard pattern. However, there is nothing to stop the server sending back a different pattern and writing over one of your other files"

I haven't used the Linux version much so I assumed it had the same option. PSCP has had this option for as long as I can remember. I guess no one bothered to look at scp, or as one of the other comments here notes, scp is overwhelmingly used with a server one already trusts.

Re: 35-year-old vulnerability discovered in scp

#66

Post by JdeBP »

The fact that OpenSSH's refresh_progress_meter() does not pass filename strings through vis(3) is a bug in its own right, irrespective of whether it can be abused for things like this.

The progress meter is meant to be a single line, and the formatting calculations simplistically assume that every character in the buffer is a (single-width) graphic or SPC. Anything in the filename that breaks that will disrupt the progress meter.

Re: 35-year-old vulnerability discovered in scp

#67

Post by eecc »

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…

Uhm, the attacker might not be able to compromise your systems beyond the exploit that gave out your server, but might use this to reach out into your admin box and steal the keys to the kingdom.

Re: 35-year-old vulnerability discovered in scp

#68

Post by isodude »

h1d wrote: post #48
jakobegger wrote: post #16

Earlier quoted context omitted.

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.

Trivial but who does that when? I never even learnt what I should compare that with and just accepted everything (and have been safe that way).

The best way to ensure that keys are correct, is to git a file like .ssh/known_hosts2 and add known keys to that file before you connect to the server.

How you get the public key is up to you, but they are located in /etc/ssh/ on the server, or given to you when creating the server.

ssh-keyscan can scan a host and print the keys as well.

If you also add the servers to .ssh/config you also get tab completion.

It takes a bit more job to do, but it feels much safer afterwards, and it's a good routine.

Re: 35-year-old vulnerability discovered in scp

#69

Post by amelius »

detaro wrote: post #52
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 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?

Re: 35-year-old vulnerability discovered in scp

#70

Post by pbhjpbhj »

willvarfar wrote: post #25
jedberg wrote: post #18

Earlier quoted context omitted.

I see so in the case that I scp from an untrusted host, I could have added risk that it is silently overwriting filed in my local home dir. That makes sense I suppose. I never scp files from untrusted hosts, nor can I think of a use case to do so, so it hadn’t really crossed my mind.

You should not trust the server. The server may have been compromised.

The client may have also been compromised, you may have, you might be in the Truman show ... /s

If I'm reading the OP right, whilst directory permissions can be modified, traversal is not possible, so it can't overwrite outside the directory you're writing to. But if you wrote to your home directly then your .bashrc could be modified ... and it sounds like other vulnerabilities allow the actual processing to be hidden (spoofed console output).

Seems like the sort of thing that could be used in a spear-fishing scenario.

I wonder if you could write a StackExchange answer with instructions to scp files from such-and-such server ...

Post reply on HN