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

131–140 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#131

Post by jolmg »

blattimwind wrote: post #128
jolmg wrote: post #119

Earlier quoted context omitted.

If you write: scp server:readme.txt . "readme.txt" is still shell code. Most shells will evaluate it to the string "readme.txt", but scp on the client should not make assumptions of the shell used on the server. If you write: scp server:'*.txt(oc[1,10])' . A server that's setup with zsh with extended globs is going to return the newest 10 .txt files. If scp is written with an expectation of basic globs, I imagine it…

Classic langsec failure.

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

Re: 35-year-old vulnerability discovered in scp

#132

Post by teacpde »

freiheit wrote: post #124
teacpde wrote: post #122

> Due to accepting and displaying arbitrary stderr output from the scp server, a malicious server can manipulate the client output, for example to employ ANSI codes to hide additional files being transferred. Can someone explain how “employ ANSI codes to hide” works?

Your client asks for 1 file, the server comes back with 2 files (the 2nd one what you actually asked for), but the name of the first (tiny) file's name contains escape sequences that clear the line, move up a line, or otherwise obscure that the first file was sent.

Awesome, found https://en.wikipedia.org/wiki/ANSI_escape_code and played a bit in my terminal. It is fun.

    $ echo -e "hello\n\e[1A[2K\rworld"                                                                      
    $ world

Re: 35-year-old vulnerability discovered in scp

#133

Post by rkeene2 »

unilynx wrote: post #47
kurlberg wrote: post #37

Earlier quoted context omitted.

Throughout the years my employers have reinstalled servers and consequently changed host keys. I believe many users just accept the new key without realizing what they might get themselves into. Ideally your organization should keep updated (public) host keys somewhere, say on some https-protected website so you can double check yourself. How common is this? (I mainly use ssh for interactive/tunneling use, but with a…

Ideally they set up SSHFP dns records with the hostkey fingerprints Haven't yet encountered it in the wild though

OpenSSH also supports certificates, so you can have the host system provide a certificate identifying it -- but you have to setup a CA, and arrange for new hosts to securely have their host keys signed by it.

Re: 35-year-old vulnerability discovered in scp

#134

Post by fwip »

nothrabannosir wrote: post #120
aaronmdjones wrote: post #111

Earlier quoted context omitted.

No, the way to solve this is to use client public key authentication. Then a successful MITM will require the client's private key too.

No, it will only require the public key (which is public) to impersonate the server. It won’t be a MITM but it’s still bad; see e.g. the bug in this very article, or if (god forbid) you’ve set up agent forwarding. Or if you do e.g. a git pull from github on a fresh comp, it can serve you bad code. Asymmetric key is not a solution to the problem of users blindly trusting hosts without checking the fingerprint. It’s a…

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

Re: 35-year-old vulnerability discovered in scp

#135

Post by jolmg »

blattimwind wrote: post #93

Honestly this seems a bit disappointing to me. Reading the issue description scp sounds like the following pseudo-code: sock = connect(server) sock.do_crypto() sock.send_filelist(commandline.list) cd(commandline.targetdir) while not sock.eof: write_to_local_disk(sock.receive_file()) i.e. blindly create and change files the server tells the client about. Complete lack of client-side verification.

> sock.send_filelist(commandline.list)

Instead of a "filelist", it's got to be a remote shell command argument, since it allows stuff like:

    scp server:'$(
      comm -23 \
I'm not sure what you propose for client-side verification in this case.

Re: 35-year-old vulnerability discovered in scp

#136

Post by syn0byte »

teacpde wrote: post #122

> Due to accepting and displaying arbitrary stderr output from the scp server, a malicious server can manipulate the client output, for example to employ ANSI codes to hide additional files being transferred. Can someone explain how “employ ANSI codes to hide” works?

#!/bin/bash

echo "Magic!" echo -en "\033[1F\033[2K" echo "Moar Magic!"

This script will print "Magic!" then the next echo sends escape sequences that move the cursor up 1 line with '\033[1F', then '\033[2K' clears the line the cursor is on, which is now the "Magic!" line. Then we output "Moar Magic". 3 commands but only one line of output.

The -e option on echo enables the escape sequences instead of literal chars. -n disables echos automatic newline for the sequence that deletes the first line

scp servers can of course do all the same trickery.

Re: 35-year-old vulnerability discovered in scp

#137

Post by cbhl »

walrus01 wrote: post #126
userbinator wrote: post #65

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…

I strongly discourage anyone from using PuTTY, not for this reason, but for its weird and nonstandard handling of SSH keys. The last time I tried to help someone get it set up on a windows PC, totally normal ssh2 rsa 2048 and 4096 bit public/private key pairs created with openssh had to be converted into some other weird format before they could get public/private key auth working. Why the developers of putty felt th…

PuTTY's changelog from 2000 shows that PuTTYgen uses "the same RSA key file format as SSH 1" (the proprietary one, that predates OpenSSH).

Reading and writing OpenSSH-style keys came later (2012).

https://www.chiark.greenend.org.uk/~sgtatham/putty/changes.h...

Re: 35-year-old vulnerability discovered in scp

#138

Post by blattimwind »

jolmg wrote: post #131
blattimwind wrote: post #128

Earlier quoted context omitted.

Classic langsec failure.

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. something that reduces to REs).

Re: 35-year-old vulnerability discovered in scp

#139

Post by nothrabannosir »

fwip wrote: post #134
nothrabannosir wrote: post #120

Earlier quoted context omitted.

No, it will only require the public key (which is public) to impersonate the server. It won’t be a MITM but it’s still bad; see e.g. the bug in this very article, or if (god forbid) you’ve set up agent forwarding. Or if you do e.g. a git pull from github on a fresh comp, it can serve you bad code. Asymmetric key is not a solution to the problem of users blindly trusting hosts without checking the fingerprint. It’s a…

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 Eve, so Alice will connect to Eve. Really this is nothing different from just connecting to a fresh host: you upload your public key to the remote ~/.ssh/authorized_keys somehow, and voila, right? How does your ssh client know that was the same server? The fingerprint. Did you check it? No.

Check out this article:

> The more well-discussed use of asymmetrical encryption with SSH comes from SSH key-based authentication. SSH key pairs can be used to authenticate a client to a server. The client creates a key pair and then uploads the public key to any remote server it wishes to access. This is placed in a file called authorized_keys within the ~/.ssh directory in the user account's home directory on the remote server.

> After the symmetrical encryption is established to secure communications between the server and client, the client must authenticate to be allowed access. The server can use the public key in this file to encrypt a challenge message to the client. If the client can prove that it was able to decrypt this message, it has demonstrated that it owns the associated private key. The server then can set up the environment for the client.

- https://www.digitalocean.com/community/tutorials/understandi...

As you can see, ssh public key auth authenticates the user, not the host. anyone could be that host.

Now: you as a human will quickly notice "where is my homedir? wait a second... this is not Bob—This is Eve!" the question is: quickly enough? If you were using scp: no, look at TFA. If you were connecting to github for the first time using git, perhaps using homebrew on a fresh machine: now you'll definitely never know. If you had set up your ssh key agent to forward keys to your "trusted" Bob host: serious trouble. There are loads of reasons why intercepting an SSH connection is a dramatic bug, even without being able to MITM it.

Or just try and turn it around: why do you think SSH prompts you to confirm the host key fingerprint, if it doesn't matter? For fun? They didn't add that as a joke.

Alas, few people understand this, as you so elegantly demonstrated :/

Re: 35-year-old vulnerability discovered in scp

#140

Post by m45t3r »

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.

SSH saves the host identification in .known_hosts file. So after the first connection (that asks you if you know this key, and sure, nobody verifies it) you known for sure that this is the server that you want to connect.

If after all that you receive a message an error from SSH that the host key identification changed, you didn't change this key yourself (or your team) and you still blindly ignore this issue (since it is not easy to bypass either, there is no flag, for example), this is not an UI issue and you're responsible for your actions.

Post reply on HN