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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]