35-year-old vulnerability discovered in scp
sintonen.fi
35-year-old vulnerability discovered in scp
1–10 of 158 posts
Re: 35-year-old vulnerability discovered in scp
#2I 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/?
Re: 35-year-old vulnerability discovered in scp
#3Could anyone comment about whether any file-related Ansible modules use scp by default instead of sftp?
Re: 35-year-old vulnerability discovered in scp
#4I 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/?
> 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.
Re: 35-year-old vulnerability discovered in scp
#5I 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/?
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.
Re: 35-year-old vulnerability discovered in scp
#6Could anyone comment about whether any file-related Ansible modules use scp by default instead of sftp?
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.
Re: 35-year-old vulnerability discovered in scp
#7I 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/?
> 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 compromis…
> 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).
Re: 35-year-old vulnerability discovered in scp
#8I 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/?
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).
Re: 35-year-old vulnerability discovered in scp
#9I 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/?
> 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 compromis…
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)
Re: 35-year-old vulnerability discovered in scp
#10I 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.