Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Peter W (peterwusa.net)
Date: Tue Sep 18 2001 - 07:24:07 CDT
OpenSSH: sftp-server & bypassing keypair auth restrictions
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.
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.
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.
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
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).
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.
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.
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.
-- http://www.tux.org/~peterw/ Encryption advocacy resources: http://vees.net/freedom/