7132700 2001-09-18 08:24 -0400 /125 rader/ Peter W <peterw@usa.net> Sänt av: joel@lysator.liu.se Importerad: 2001-09-18 23:50 av Brevbäraren Extern mottagare: bugtraq@securityfocus.com Mottagare: Bugtraq (import) <19228> Ärende: OpenSSH: sftp & bypassing keypair auth restrictions ------------------------------------------------------------ From: Peter W <peterw@usa.net> To: bugtraq@securityfocus.com Message-ID: <20010918082406.M14947@usa.net> OpenSSH: sftp-server & bypassing keypair auth restrictions Summary: If you 1) are using keypairs and ~/.ssh/authorized_keys2 to enable remote execution of commands via OpenSSH's sshd and 2) have sshd configured to provide sftp service via the sftp-server subsystem, then clients who have access with "restricted" keypairs can gain additional access on the server side. In most cases, sftp can be used to evade the authorized_keys2 command= and other restrictions (i.e., obtaining the regular shell access that the server was configured to deny them). It appears that both OpenSSH 2.9 (the official OpenBSD code) and OpenSSH 2.9p2 (the official "portable" code for other systems) by default *do* have the sftp subsystem enabled, and their users would be vulnerable if they set up restricted keypairs. Disclaimer: This has been tested with OpenSSH 2.5x and 2.9x. *No* testing has been done on any other implementations, including the commercial product from SSH Communications, so I cannot speak to the safety of other implementations. Hopefully this defect is only present in OpenSSH. Regrettably, this information is correct to the best of my knowledge. This information is provided with the sole aim of helping admins secure their systems, without any warranty or guarantee of any sort. Background: OpenSSH allows clients to authenticate to the sshd service via RSA and DSA public key authentication. It also allows users on the sshd server to restrict what clients presenting certain keypairs can do. For instance, a backup system might use keypair authentication to encrypt network traffic and strongly verify the identity of both server and client machines. On the machine being backed up, the backup system's keypair would be recognized as having authorization to run one or more appropriate backup commands. OpenSSH also implements an FTP-like sftp service as a "subsystem" to allow secure file transfer (both as an alternative to 'scp' and to allow additional commands not provided by 'scp'). While OpenSSH allows a user to place many kinds of restrictions on what a client authenticating with a keypair can do (where they can connect from, what commands they can run, whether to forward TCP/X/ssh-agent info), it is *not* possible to prevent the client from using the sftp subsystem. Clients presenting otherwise restricted keypairs can use the sftp subsystem to access the sshd machine with an interface very similar to FTP. Various commands are provided in OpenSSH's sftp implementation, including commands to get, replace, delete, change permissions, and change ownership of files/directories. Problem scenario: You've got production server Important You've got backup server DumbTape You've got a backup script on Important You've got a keypair on DumbTape You've configured a ~/.ssh/authorized_keys2 file on Important so that one certain keypair from DumbTape can use scp/ssh to very securely run the backup script, and only the backup script, on Important Your private keypair on DumbTape lacks a password, to facilitate cron use Problem: Anyone who gets access to the private keypair on DumbTape can use the sftp client to connect to Important. They can use sftp subsystem to poke all around Important, reading, replacing, chowning, chmoding, and deleting data with all the privileges of the user on Important that the backup script runs as, via that user's ~/.ssh/authorized_keys2 file on Important. This unfortunately includes the ability to manipulate ~/.ssh/authorized_keys2 itself. The attacker can replace authorized_keys2 with a new version that allows them full SSH access. If the user whose ~/.ssh/authorized_keys2 file is being changed relies solely on keypair authentication, the attacker can easily disable the legitimate user's access via ~/.ssh/authorized_keys2. By manipulating the legitimate user's local .login/.profile files, the attacker likely can prevent logins that use passwords or other non-keypair authentication methods as well. So if you follow the example in the OpenSSH man page: command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 back-up.hut.fi (running as root, naturally), then anyone who obtains the backup machine's SSH keypair can get a root shell and effectively lock out the real administrator (install a new SSH public key, change the root password). Solution: The OpenSSH development team (Markus Friedl) have committed a patch to CVS that is intended to make the command= restriction override any subsystem capability, including sftp. I'm not sure that's the most correct approach (vs. a subsystem= restriction), but it should plug the hole if it behaves as described. Not needing sftp service, I have simply disabled the sftp subsystem on my systems. I don't know when this patch might be available in an official/stable release. I would also suggest that OpenSSH's sshd_config file have the sftp subsystem disabled by default. Workaround: Until an official fix is released, disable the sftp subsystem on your sshd machines by editing sshd_config (comment out or remove the sftp subsystem line) and restarting the sshd service. This will not affect the ability of users on the system to use sftp client software to connect to other servers that still have the sftp subsystem available. In some situations, more likely with non-root users on the sshd/Important side, it might be possible to use filesystem ownership tricks (assigning objects to other users, using sticky bits, using "immutable" flags on filesystems that offer such things) to better protect the sshd host, especially the critical ~/.ssh/ files. While this should raise the bar for an attacker (e.g., making them find other ways/places to install trojan backdoors), it it likely to be an imperfect shield, and would in any case not prevent unauthorized read/write access to much of the Important system. Each admin should undertake their own risk analysis, but simply disabling the sftp subsystem is the simplest, most reliable way of protecting against this threat. Credits: Thanks go to Tatu Ylonen for releasing source and specification for SSH; to the OpenSSH team for their work in developing and maintaining a free implementation; Richard Silverman, Markus Friedl, and others for looking at this; and all the folks working hard to care for the victims of last week's attack, to find justice, and to safeguard our liberties in the face of uncertainty and fear. -Peter -- http://www.tux.org/~peterw/ Encryption advocacy resources: http://vees.net/freedom/ (7132700) /Peter W <peterw@usa.net>/------(Ombruten)