dotancohen at gmail
May 13, 2012, 7:32 AM
Post #16 of 34
(906 views)
Permalink
|
|
Re: Transferring file to local machine when SSHing into a foreign box
[In reply to]
|
|
On Sun, May 13, 2012 at 4:47 PM, Ángel González <keisial [at] gmail> 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] loca:~$ ls
file1 file2
me [at] loca:~$ ssh anotherMe [at] remot
anotherMe [at] remot:~$ ls
document1 document2
anotherMe [at] remot:~$ cpLocal document1
---------------------------------- <-- Here opens a "VIM-window" (see above)
| me [at] loca: Download document1? |
| [y/N/r/l]? | <-- 'r' is Rename, 'l' is Choose Location
anotherMe [at] remot:~$ exit
me [at] loca:~$ ls
document1 file1 file2
me [at] loca:~$
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|
1
