Bug#327019: ssh: scp allows remote execution of shell commands when semicolon is used in filename
severity 327019 normal
thanks
On Wed, Sep 07, 2005 at 12:36:03PM +0700, Alexey Feldgendler wrote:
> Package: ssh
> Version: 1:3.8.1p1-8.sarge.4
> Severity: critical
>
> Here is my testcase:
>
> $ scp remotehost@';uname -a'
> Linux pancake 2.6.11-1-686 #1 Mon Jun 20 22:00:38 MDT 2005 i686 GNU/Linux
>
> That line comes from the remote host (I verified this by trying
> hostname command instead of uname -a, that gives the name of the
> remote host).
>
> I also tried connecting to my own machine this way (localhost@), and
> it executes arbitrary commands, too. So I won't put the versions of
> packages on the remote host here, because the ssh server on the local
> host is vulnerable as well.
>
> I'm not sure that this is a security hole because a user can anyway
> connect with ssh and execute arbitrary commands. But it can possibly
> be a vulnerability if the user account has a restricted shell, or PAM
> restrictions that allow scp but disallow ssh are in effect.
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.
Any sensible restricted environment allowing scp either as client or
server will sanitise the arguments carefully (and it's most definitely a
bug in that restricted environment if it fails to do so); if you want to
avoid the character escaping problems, use something based on SFTP
instead. See <http://www.openssh.org/faq.html#2.10>.
I'm not sure it's even possible to write PAM restrictions that allow scp
but disallow ssh, precisely because it's just a simple shell-based
protocol. If it is possible, then they would have to do shell command
parsing or similar anyway; scp does not open any new methods of
executing remote commands that did not already exist.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: