Transferring file to local machine when SSHing into a foreign box

Ángel González keisial at gmail.com
Sun May 13 23:47:36 EST 2012


On 13/05/12 12:41, Dotan Cohen wrote:
> On Sun, May 13, 2012 at 1:06 PM, Ángel González <keisial at gmail.com> wrote:
>> If a command such as the proposed cp2local is able to write arbitrary
>> files in the local end*, it allows such compromise.
>>
> I understand that you feel that allowing the remote server to write
> (not execute) arbitrary files to the local machine is a security risk.
Yes

> I also assume that you do not feel that scp being able to write
> arbitrary files to the local machine is not a security risk because it
> requires the explicit typing of a username and password, or better yet
> of a keypair. Please confirm or deny if my assumption is correct.
No. It is not a security risk because the user explicitely and
unambiguously provides the target filename.


> I counter that the proposed cp2Local is no more of a security risk
> than scp because it _also_ requires the user of a username/password or
> keypair to explicitly express intent (establishing the initial SSH
> connection).
Connecting to a malicious host != downloading files.

> Assuming the worst-case scenario that this feature is
> enabled and the user SSHes into a compromised box, the user will be
> only downloading unwanted, malicious files to his local machine,
...and potentially getting valuable data overwritten
> he will not be executing them automatically. 
Unless the arbitrary name the file is saved as, is one which lead to
other programs to automatically execute it.

> This is no different than visiting a webpage. In fact, this is safer: web browsers _can_ run
> arbitrary code in the form of Javascript.
JavaScript runs in a sandbox and can't modify your files.
A better analogy would be a document macro.

You open the document. But that doesn't mean you want to allow its macro
to spread to all your documents and email new copies to your contact book.


> You could argue that the web browser downloads to a cache, whereas
> cpLocal would download to $HOME. Therefore have it downlaod to a
> different directory, Free Desktop has conventions for this, see this
> Stack Overflow discussion:
> http://unix.stackexchange.com/a/15238/9760
I usually wouldn't want to get it to a Download folder. However, that
would indeed solve the security issue.

I assume you change your request to a
 cp2local <file>
command, which copies <file> into $HOME/Downloads
 (or another folder configured in ssh_config), and the user is
responsible for moving it from there to wherever they want in the local
folder?


> In short, I recognise the problem of allowing the remote machine
> access to write to your local machine. However, this has been a
> problem with many other technologies (www, email, ftp, etc.) and it is
> a solved issue in the general sense. That is, best practices and
> damage-mitigation strategies have already been established.
The CVE that I provided (the web server being able to control the
destination filename), was fixed in wget by disabling that feature by
default :)




More information about the openssh-unix-dev mailing list