Bug#327019: ssh: scp allows remote execution of shell commands when semicolon is used in filename
On Mon, Sep 12, 2005 at 10:17:39AM +0700, Alexey Feldgendler wrote: Colin Watson wrote: 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? Yes, it will break the scp protocol because the server end isn't expecting that, and you can't change the server end because then you'd become incompatible with old clients. This cannot be fixed in scp because there is no provision for revising the protocol. Use sftp. 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.) That's an old and fairly well-known bug, yes, but cannot be fixed in scp without breaking the protocol. Use sftp. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED]:';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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327019: ssh: scp allows remote execution of shell commands when semicolon is used in filename
severity 327019 grave 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). If this is a security bug, then it would seem to be a grave (user security hole) bug, not a critical (root security hole) bug. 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. I haven't checked these cases, but I set this bug's severity to critical just in case it really turns out to be a security hole. Ok, so if you configure your server to *disallow* arbitrary command execution via ssh, does this scp command still work? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#327019: ssh: scp allows remote execution of shell commands when semicolon is used in filename
On Wednesday, September 07, 2005 6:36 AM, Alexey Feldgendler [EMAIL PROTECTED] wrote: Package: ssh Version: 1:3.8.1p1-8.sarge.4 Severity: critical Here is my testcase: $ scp remotehost@';uname -a' scp [EMAIL PROTECTED]:';uname -a', surely? Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327019: ssh: scp allows remote execution of shell commands when semicolon is used in filename
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. I haven't checked these cases, but I set this bug's severity to critical just in case it really turns out to be a security hole. In addition to being or not being a security hole, it's also a major bug that prevents from transferring files with special characters in names via scp. The workaround is to escape them with backslashes. (Because you are typing the scp command itself in a shell, the backslashes themselves, along with the other special characters, need to be escaped, too.) The user that I was authenticating as had /bin/bash as his shell. The version of bash package is 3.0-15. Below is my /etc/ssh/sshd_config. # Package generated configuration file # See the sshd(8) manpage for details # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 600 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Change to yes to enable tunnelled clear text passwords PasswordAuthentication no # To change Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #AFSTokenPassing no #KerberosTicketCleanup no # Kerberos TGT Passing does only work with the AFS kaserver #KerberosTgtPassing yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes KeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net Subsystem sftp/usr/lib/sftp-server UsePAM yes -- System Information: Debian Release: testing/unstable APT prefers testing-proposed-updates APT policy: (900, 'testing-proposed-updates'), (900, 'testing'), (900, 'stable'), (800, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Versions of packages ssh depends on: ii adduser3.67 Add and remove users and groups ii debconf1.4.57Debian configuration management sy ii dpkg 1.13.11 package maintenance system for Deb ii libc6 2.3.5-6 GNU C Library: Shared libraries an ii libpam-modules 0.76-23 Pluggable Authentication Modules f ii libpam-runtime 0.76-23 Runtime support for the PAM librar ii libpam0g 0.76-23 Pluggable Authentication Modules l ii libssl0.9.70.9.7e-3 SSL shared libraries ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime ssh recommends no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
