Bug#327019: ssh: scp allows remote execution of shell commands when semicolon is used in filename
Sorry, gentlemen, I wasn't checking my mail for a while.
Ok, so if you configure your server to *disallow* arbitrary command
execution via ssh, does this scp command still work?
How can I do it? I don't know how it is done.
$ scp remotehost@';uname -a'
scp [user]@remotehost:';uname -a', surely?
Oh yes, really, sorry for that mistake.
scp's protocol has always been this way (it is essentially just 'ssh
remotehost scp -f/-t ...'), and there isn't much that can be done about
it at this stage without breaking compatibility with other systems. Yes,
it's broken and annoying, but it doesn't open any new security holes
because it's just using ssh's standard facilities for executing remote
commands; the scp server, such as it is (just scp with some extra
options) does not execute those commands itself.
Why can't scp just escape all suspicious characters with backslashes
before giving them to the shell? Will that break anything?
Aside from security issues, this bug has also a practical implication: scp
can't be easily used to download files whose names contain spaces or other
nasty characters. (That was how I found the bug.) To actually specify
these, they need to be escaped twice: once to hide them from the local
shell, and once from the remote shell.
scp remotehost:file\\\ with\\\ spaces .
or
scp remotehost:'file\ with\ spaces' .
--
Alexey Feldgendler
Plesk for UNIX Developer
SWsoft, Inc.
Reply to: