14 ms·

35-year-old vulnerability discovered in scp

601 points by runn1ng 8y ago

mfontani 8y ago
I read: * [...] only directory traversal attacks are prevented * [...] can overwrite arbitrary files in the scp client target directory * [...] the server can manipulate subdirectories as well ... so nothing points to the ability of the server to "fiddle with" parent directories. Thus.. Is it an OK temporary workaround to _only_ perform scp from within a freshly created directory in /tmp/?
- askmike 8y ago
  > The attacker controlled server [...] drops .bash_aliases file to victim's home directory when the victim performs scp operation from the server. The transfer of extra files is hidden by sending ANSI control sequences via stderr. [...] Once the victim launches a new shell, the malicious commands in .bash_aliases get executed. Sounds to me like everything the user executing the scp command can access can be compromised.
  - leni536 8y ago
    > The attacker controlled server [...] drops .bash_aliases file to victim's home directory This can only happen if scp is invoked from the home directory (or from root or /home).
    - reacweb 8y ago
      The server could also drop a "ls" file with execution rights in current directory. If "." is in your path before /usr/bin (I have already encounter that), it may be called as soon as you type ls (generally just after the scp).
      - leni536 8y ago
        Sure, it can also drop filenames starting with a dash, filenames with spaces/newlines in it and all sorts of stuff. These can cause all kind of havoc in poorly written scripts. Having "." in your path is an obvious misconfiguration too.
        reacweb 8y ago
        Having a trailing : at the end of the PATH is the same as :. and occurs quite often.
  - jakobegger 8y ago
    That example requires the user to copy something to the home directory. If you copy something to /tmp, or to a subdirectory of your home directory, that attack is not possible (according to my understanding)
- Lex-2008 8y ago
  Reading > Malicious scp server can write arbitrary files to scp target directory looks like you don't need to `cd /tmp` before running scp, it's enough to scp _to_ a freshly created directory (`scp host:file /tmp/dir1`), inspect its contents and `rm -rf /tmp/dir1` afterwards.
- korpiq 8y ago
  I read it as being MitM and manipulating target (final, originally intended server) directories and files only, and in addition to spoof output to client to hide the fact it's doing so. In that case it does not matter where you run the client. What makes MitMs possible is that checking fingerprint of new host is left to user. Instead we should have processes to automatically 1. acquire via other means and add fingerprint of each new target host 2. verify new host fingerprints with a separate party (central server or a ring of trusted buddies).
  - Thorrez 8y ago
    If you let a something MITM you it will always be able to steal your files, no path validation will fix that. If you let something MITM you when copying files from client to server it should have no way of changing the destination directory (assuming you authenticate using asymmetric crypto), regardless of path validation. This vulnerability has nothing to do with that. This vulnerability is only about copying files from the server to the client, and lacking path validation when that happens. This problem can be fixed without fixing MITM.
  - jakobegger 8y ago
    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.
    - h1d 8y ago
      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).
      - isodude 8y ago
        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.
kakarot 8y ago
Could anyone comment about whether any file-related Ansible modules use scp by default instead of sftp?
- evgen 8y ago
  I believe you need to set scp_if_ssh = True in ansible.cfg for scp to ever be used, even if sftp is not available on the remote host.
  - jabl 8y ago
    Nowadays ansible uses a sort-of 'smart' method by default, where it first tries to use sftp, and if that fails, falls back to scp. See https://docs.ansible.com/ansible/latest/plugins/connection/ssh.html https://docs.ansible.com/ansible/latest/plugins/connection/s...
    - zurn 8y ago
      So if the server is compromised, it can fail the sftp in a suitable way? But its another matter if ansible's scp client is vulnerable to this.
    - kakarot 8y ago
      So if anyone is curious, the way to prevent this is: scp_if_ssh = false
jedberg 8y ago
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 host keys, then you're completely breaking the ssh security model anyway. I guess I don't understand how this is actually any worse than how ssh already worked? Edit: To clarify, I understand why you’d want to fix this, for a good depth of defense. I’m just saying I don’t feel any urgency in fixing this.
- bryanrasmussen 8y ago
  reminds me of this raymond chen post https://blogs.msdn.microsoft.com/oldnewthing/20121207-00/?p=5893 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."
  - bryanrasmussen 8y ago
    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.
  - Dylan16807 8y ago
    This is getting [partial] control of every machine that merely downloads a file from the one you took over.
- joelthelion 8y ago
  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.
  - dmurray 8y ago
leni536 8y ago
I quick test with strace and git shows that git doesn't use scp for handling ssh remotes. I suspect that git is hardened against similar attacks (a malicious server dropping files into .git/hooks would be worrisome).
- fulafel 8y ago
  Git recently had a malicious-server-rce bug, though not related.
aaaaaaaaaab 8y ago
It’s easy to fix. Just rewrite scp in Rust.
- saagarjha 8y ago
  There are no memory corruption issues here, so I'm not sure how much this would help.
- dang 8y ago
  Please don't post unsubstantive comments here.
- ben_bai 8y ago
  As long as you use vi to write your rust code I'm OK.
deleted 8y ago
[deleted]
userbinator 8y ago
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.html 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.
- jolmg 8y ago
  > 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 https://news.ycombinator.com/item?id=18912188
- walrus01 8y ago
  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 they needed to deviate from standard ssh2-rsa pub/privkey formats is a mystery to me.
  - rjbwork 8y ago
    It's quite easy. There are multiple tutorials on it. When you load up a key into putty the plain old key you're used to is sitting right there in a box in the app. Just copy.
JdeBP 8y ago
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.
blattimwind 8y ago
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.
- jolmg 8y ago
  > 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 \ <(find dir1 -type f -printf "%P\n" | sort) \ <(find dir2 -type f -printf "%P\n" | sort) \ | sed "s:^:dir1/:" )' . I'm not sure what you propose for client-side verification in this case.
kazinator 8y ago
> 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.
- dancek 8y ago
  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 8y ago
    [deleted]
  - deleted 8y ago
    [deleted]
  - kakarot 8y ago
    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 trust your server's host key at all. Either they have a valid certificate or they don't. Your SSH client won't even ask you if you trust the server. It's one thing to access a compromised server, but you should NEVER be exposed to MITM attacks with proper SSH usage, except for your very first connection on a brand-spanking new server when you drop your SSH host certificates (ideally in an automated fashion which can be deployed immediately after spinning up your box).
    - dancek 8y ago
jolmg 8y ago
> 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.
- rtkwe 8y ago
  At the very least the client could perform a check that the files it's receiving match the pattern it sent in the request by using a regular expression replacing * with an non-whitespace+forbidden character. It doesn't even check that if you request a single file like readme.txt that it receives a single file!
  - jolmg 8y ago
    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 would try to match the files that have a character-by-character literal extension of ".txt(oc[1,10])". That means no file is ever going to match. You could say, "well, add recognition of zsh extended globs". Ignoring how complicated that really is because there are glob options that allow you to embed arbitrary zsh code, you're limiting the implementation of scp to work with only particular shells. scp should not be a barrier to me implementing my own shell, with it's own syntax and using it transparently. The current scp doesn't care about what shells you use where. It makes little to no assumptions of the tools you use, and that's cool.
mLuby 8y ago
SCP-035 has breached containment. Oh whoops wrong context.
- teilo 8y ago
  It was inevitable.
sealthedeal 8y ago
Ultimately it is a MITM attack, correct?
teacpde 8y ago
> 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?
- freiheit 8y ago
  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.
  - teacpde 8y ago
    Awesome, found https://en.wikipedia.org/wiki/ANSI_escape_code 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
- syn0byte 8y ago
  #!/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.
winkywooster 8y ago
How is it a 35 year old vulnerability? ssh and friends have only been around for 25.
- cosmotron 8y ago
  I believe the title is derived from the description of vulnerability #2: > Due to the scp implementation being derived from 1983 rcp [1] ... > [1] https://www.jeffgeerling.com/blog/brief-history-ssh-and-remote-access https://www.jeffgeerling.com/blog/brief-history-ssh-and-remo...
cryptonector 8y ago
This is just another in the series of rcp/scp considered harmful "bugs". This isn't a bug -- rcp/scp are the bug. Use sftp to fetch files. rcp/scp are fine for pushing files upstream, but not for fetching.
tzhenghao 8y ago
uhh I think we killed it lol. $ ping sintonen.fi PING sintonen.fi (95.216.45.180): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 ...

601 points by runn1ng 8y ago

I read: * [...] only directory traversal attacks are prevented * [...] can overwrite arbitrary files in the scp client target directory * [...] the server can manipulate subdirectories as well ... so nothing points to the ability of the server to "fiddle with" parent directories. Thus.. Is it an OK temporary workaround to _only_ perform scp from within a freshly created directory in /tmp/?

askmike 8y ago
> The attacker controlled server [...] drops .bash_aliases file to victim's home directory when the victim performs scp operation from the server. The transfer of extra files is hidden by sending ANSI control sequences via stderr. [...] Once the victim launches a new shell, the malicious commands in .bash_aliases get executed. Sounds to me like everything the user executing the scp command can access can be compromised.
- leni536 8y ago
  > The attacker controlled server [...] drops .bash_aliases file to victim's home directory This can only happen if scp is invoked from the home directory (or from root or /home).
  - reacweb 8y ago
    The server could also drop a "ls" file with execution rights in current directory. If "." is in your path before /usr/bin (I have already encounter that), it may be called as soon as you type ls (generally just after the scp).
    - leni536 8y ago
      Sure, it can also drop filenames starting with a dash, filenames with spaces/newlines in it and all sorts of stuff. These can cause all kind of havoc in poorly written scripts. Having "." in your path is an obvious misconfiguration too.
      - reacweb 8y ago
        Having a trailing : at the end of the PATH is the same as :. and occurs quite often.
- jakobegger 8y ago
  That example requires the user to copy something to the home directory. If you copy something to /tmp, or to a subdirectory of your home directory, that attack is not possible (according to my understanding)
Lex-2008 8y ago
Reading > Malicious scp server can write arbitrary files to scp target directory looks like you don't need to `cd /tmp` before running scp, it's enough to scp _to_ a freshly created directory (`scp host:file /tmp/dir1`), inspect its contents and `rm -rf /tmp/dir1` afterwards.
korpiq 8y ago
I read it as being MitM and manipulating target (final, originally intended server) directories and files only, and in addition to spoof output to client to hide the fact it's doing so. In that case it does not matter where you run the client. What makes MitMs possible is that checking fingerprint of new host is left to user. Instead we should have processes to automatically 1. acquire via other means and add fingerprint of each new target host 2. verify new host fingerprints with a separate party (central server or a ring of trusted buddies).
- Thorrez 8y ago
  If you let a something MITM you it will always be able to steal your files, no path validation will fix that. If you let something MITM you when copying files from client to server it should have no way of changing the destination directory (assuming you authenticate using asymmetric crypto), regardless of path validation. This vulnerability has nothing to do with that. This vulnerability is only about copying files from the server to the client, and lacking path validation when that happens. This problem can be fixed without fixing MITM.
- jakobegger 8y ago
  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.
  - h1d 8y ago
    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).
    - isodude 8y ago
      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.

kakarot 8y ago

Could anyone comment about whether any file-related Ansible modules use scp by default instead of sftp?

evgen 8y ago
I believe you need to set scp_if_ssh = True in ansible.cfg for scp to ever be used, even if sftp is not available on the remote host.
- jabl 8y ago
  Nowadays ansible uses a sort-of 'smart' method by default, where it first tries to use sftp, and if that fails, falls back to scp. See https://docs.ansible.com/ansible/latest/plugins/connection/ssh.html https://docs.ansible.com/ansible/latest/plugins/connection/s...
  - zurn 8y ago
    So if the server is compromised, it can fail the sftp in a suitable way? But its another matter if ansible's scp client is vulnerable to this.
  - kakarot 8y ago
    So if anyone is curious, the way to prevent this is: scp_if_ssh = false

jedberg 8y ago

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 host keys, then you're completely breaking the ssh security model anyway. I guess I don't understand how this is actually any worse than how ssh already worked? Edit: To clarify, I understand why you’d want to fix this, for a good depth of defense. I’m just saying I don’t feel any urgency in fixing this.

bryanrasmussen 8y ago
reminds me of this raymond chen post https://blogs.msdn.microsoft.com/oldnewthing/20121207-00/?p=5893 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."
- bryanrasmussen 8y ago
  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.
- Dylan16807 8y ago
  This is getting [partial] control of every machine that merely downloads a file from the one you took over.
joelthelion 8y ago
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.
- dmurray 8y ago

leni536 8y ago

I quick test with strace and git shows that git doesn't use scp for handling ssh remotes. I suspect that git is hardened against similar attacks (a malicious server dropping files into .git/hooks would be worrisome).

fulafel 8y ago
Git recently had a malicious-server-rce bug, though not related.

aaaaaaaaaab 8y ago

It’s easy to fix. Just rewrite scp in Rust.

saagarjha 8y ago
There are no memory corruption issues here, so I'm not sure how much this would help.
dang 8y ago
Please don't post unsubstantive comments here.
ben_bai 8y ago
As long as you use vi to write your rust code I'm OK.

deleted 8y ago

[deleted]

userbinator 8y ago

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

jolmg 8y ago
> 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 https://news.ycombinator.com/item?id=18912188
walrus01 8y ago
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 they needed to deviate from standard ssh2-rsa pub/privkey formats is a mystery to me.
- rjbwork 8y ago
  It's quite easy. There are multiple tutorials on it. When you load up a key into putty the plain old key you're used to is sitting right there in a box in the app. Just copy.

JdeBP 8y ago

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.

blattimwind 8y ago

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.

jolmg 8y ago
> 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 \ <(find dir1 -type f -printf "%P\n" | sort) \ <(find dir2 -type f -printf "%P\n" | sort) \ | sed "s:^:dir1/:" )' . I'm not sure what you propose for client-side verification in this case.

kazinator 8y ago

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

dancek 8y ago
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 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
- kakarot 8y ago
  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 trust your server's host key at all. Either they have a valid certificate or they don't. Your SSH client won't even ask you if you trust the server. It's one thing to access a compromised server, but you should NEVER be exposed to MITM attacks with proper SSH usage, except for your very first connection on a brand-spanking new server when you drop your SSH host certificates (ideally in an automated fashion which can be deployed immediately after spinning up your box).
  - dancek 8y ago

jolmg 8y ago

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

rtkwe 8y ago
At the very least the client could perform a check that the files it's receiving match the pattern it sent in the request by using a regular expression replacing * with an non-whitespace+forbidden character. It doesn't even check that if you request a single file like readme.txt that it receives a single file!
- jolmg 8y ago
  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 would try to match the files that have a character-by-character literal extension of ".txt(oc[1,10])". That means no file is ever going to match. You could say, "well, add recognition of zsh extended globs". Ignoring how complicated that really is because there are glob options that allow you to embed arbitrary zsh code, you're limiting the implementation of scp to work with only particular shells. scp should not be a barrier to me implementing my own shell, with it's own syntax and using it transparently. The current scp doesn't care about what shells you use where. It makes little to no assumptions of the tools you use, and that's cool.

mLuby 8y ago

SCP-035 has breached containment. Oh whoops wrong context.

teilo 8y ago
It was inevitable.

sealthedeal 8y ago

Ultimately it is a MITM attack, correct?

teacpde 8y ago

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

freiheit 8y ago
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.
- teacpde 8y ago
  Awesome, found https://en.wikipedia.org/wiki/ANSI_escape_code 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
syn0byte 8y ago
#!/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.

winkywooster 8y ago

How is it a 35 year old vulnerability? ssh and friends have only been around for 25.

cosmotron 8y ago
I believe the title is derived from the description of vulnerability #2: > Due to the scp implementation being derived from 1983 rcp [1] ... > [1] https://www.jeffgeerling.com/blog/brief-history-ssh-and-remote-access https://www.jeffgeerling.com/blog/brief-history-ssh-and-remo...

cryptonector 8y ago

This is just another in the series of rcp/scp considered harmful "bugs". This isn't a bug -- rcp/scp are the bug. Use sftp to fetch files. rcp/scp are fine for pushing files upstream, but not for fetching.

tzhenghao 8y ago

uhh I think we killed it lol. $ ping sintonen.fi PING sintonen.fi (95.216.45.180): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 ...