Transferring file to local machine when SSHing into a foreign box

[Dotan Cohen]

On Sun, May 13, 2012 at 4:47 PM, Ángel González <keisial at gmail.com> wrote:
>> 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 see. I address the filename issue in a reply to Gert. By analogy
with the web browser (which under certain condition prompts the user
to save a file in a "main" directory with a server-choosen filename),
there could be a client-side prompt to confirm / deny the cpLocal
command which was run on the host.


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

Correct, but downloading files is the only new functionality that we
are discussing. All other attack vectors are identical to current SSH
(without the feature under discussion).


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

Then the prompt will mitigate this, just as the web browser
file-download prompt.


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

Again, this is no more of a risk than downloading files with the web browser.


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

Fine, then.


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

How is that any more of a concern if the file is acquired via scp vs.
being downloaded in a web browser?


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

That would be terrific.


>> 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 :)
>
>

Actually, modelling the defaults and options on the wget defaults and
options would be terrific. However, in this case there is no URL, and
the file has to have _some_ name, so I suggest that the server
"suggest" a filename and that the prompts allow it to be overwritten.

Are you familiar with VIM's little popup windows on the bottom of the
screen, such as when typing :marks or :ls with multiple buffers? I do
know know what that feature is called, so I'll refer to it as a
VIM-popup here.

As we have described it, the cpLocal feature would work something like this:

me at local:~$ ls
file1 file2
me at local:~$ ssh anotherMe at remote
anotherMe at remote:~$ ls
document1 document2
anotherMe at remote:~$ cpLocal document1

----------------------------------    <-- Here opens a "VIM-window" (see above)
| me at local: Download document1?  |
| [y/N/r/l]?                     |     <-- 'r' is Rename, 'l' is Choose Location

anotherMe at remote:~$ exit
me at local:~$ ls
document1 file1 file2
me at local:~$


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com