OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Peter W (peterwusa.net)
Date: Tue Sep 18 2001 - 07:24:07 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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/