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

91–100 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#91

Post by organsnyder »

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.

You should still access that data in an offline manner, though—ideally:

1. Shut down the instance

2. Connect the storage as secondary storage on another (disconnected from the network) instance

3. Do forensics using your cloud provider's out-of-band management interface

4. Throw away that instance as soon as you're done

Re: 35-year-old vulnerability discovered in scp

#92

Post by [deleted] »

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.

[deleted]

Re: 35-year-old vulnerability discovered in scp

#93

Post by blattimwind »

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.

Re: 35-year-old vulnerability discovered in scp

#94

Post by kazinator »

> 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 server, why would I muck around perpetrating a scp exploit on remote users.

Re: 35-year-old vulnerability discovered in scp

#95

Post by jolmg »

> 2. CWE-20: scp client missing received object name validation [CVE-2019-6111]

> Due to the scp implementation being derived from 1983 rcp [1], the server chooses which files/directories are sent to the client. However, scp client only perform cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example overwrite .ssh/authorized_keys).

I don't understand why this is considered a vulnerability. The user provides scp server-side shell code to describe the files it wants. How's it supposed to verify object names then? Am I the only one that likes to do things like the following?[1]:

    scp server:'$(ls -t | head -1)' .
or

    scp server:'*.pdf' .
An argument could be made to have scp implement a glob pattern matcher, but that wouldn't be shell agnostic (I doubt we'd get support for zsh-style `*.pdf(oc[1,5])`) and it wouldn't include support for process substitution or any other way the user might want to specify files.

scp already describes the files it's writing to stdout. I don't see what more it can do without sacrificing usability.

The possibility of a compromised server writing things that have nothing to do with what I asked just seems like an acceptable consequence for the power scp provides.

[1] - Please, discussions about parsing ls output are besides the point, right now. Heuristics are useful too, at times, for ad-hoc portable practices.

Re: 35-year-old vulnerability discovered in scp

#96

Post by rsync »

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

"Ideally they set up SSHFP dns records with the hostkey fingerprints ..."

We (rsync.net) are doing this in 2019. A little embarrassed we haven't done it already ...

Re: 35-year-old vulnerability discovered in scp

#97

Post by dancek »

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.

Re: 35-year-old vulnerability discovered in scp

#98

Post by Aeolun »

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.

Re: 35-year-old vulnerability discovered in scp

#99

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

#100

Post by jolmg »

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

It's the latter for me. It's not just wildcards. You can use any server-side shell code you want to specify the files as if you're writing in a command argument[1]. At least, I find this tremendously useful.

[1] https://news.ycombinator.com/item?id=18912188

Post reply on HN