Skip site navigation (1)Skip section navigation (2) 
Date:      Tue, 25 Jan 2000 11:30:11 +0100 (MET)
From:      Marc SCHAEFER <schaefer@alphanet.ch>
To:        linux-leman-annonces@alphanet.ch, security@freebsd.org, security@redhat.com, security@ssh.org, security@suse.de, security@openbsd.org
Subject:   sshd and pop/ftponly users incorrect configuration
Message-ID:  <Pine.LNX.4.10.10001251128120.14396-100000@vulcan.alphanet.ch>
next in thread | raw e-mail | index | archive | help 
NAME
   sshd-restricted-users-incorrect-configuration

AUTHOR
   Marc SCHAEFER <schaefer@alphanet.ch>
   Andreas Trottmann <andreas.trottmann@werft22.com>

THANKS
   OpenBSD security team

VERSION
   $Id: sshd-restricted-users-incorrect-configuration,v 1.2 2000/01/25 10:27:56 schaefer Exp $

ABSTRACT
   In some cases where a system must be configured so that specific
   users only have access to POP or FTP (or a specific restricted shell,
   e.g. a BBS or lynx menu), the addition of the SSH protocol server
   (sshd) may create a security hole. The user, if they try to access
   the server per telnet succeed, but they are immediately thrown
   out (because their shell is /bin/false, e.g.), or a special restricted
   shell runs (e.g. they can change their passwd, etc). In that case,
   using sshd may create a subtle security hole allowing those users to,
   like normal users, use the SSH protocol to issue TCP connections coming
   from the attacked host.

IMPACT
   Any remote user with an account on the machine, even without real shell
   access, may open a TCP connection which will:

      - appear to be open from root@localhost (in the IDENT identd
        protocol)

      - be able to connect to any services which are not firewalled on
        the loopback (even if they are firewalled or tcp_wrapper tcpd
        protected from the outside).

      - be able to connect to any remote machine from the attacked host,
        the connection appearing to come from the attacked host with
        a wrong IDENT (see above).

IMMUNE CONFIGURATIONS
   You are immune to this problem if one (or more) of the following
   is true:

      - the group(s) where those users belong to is listed in
        /etc/ssh/sshd_config or equivalent configuration file as
           DenyGroups group1 group2  # etc
        (this is the recommended setup)
       
      - no user which has an account hasn't a shell (he will be able
        to do the above, except the root@ IDENT, anyway, if he has a shell)

      - your POP or FTP users do not authentify against the system
        password database (/etc/{passwd|shadow}), but against a
        private database and the user is locked in the system password
        database (passwd -l).

      - you only allow RSA authentification, and the users cannot modify
        their ~/.ssh from e.g. FTP.

      - you do not run sshd. Have TcpAllowForwarding to no in the
        configuration file doesn't seem to work, since
        it only denies -R style forwarding.

OPERATING SYSTEMS
   UNIX

FIX
   - There is no fix for the root@ IDENT bug for legitimate user.
     This is presumably a bug in ssh-1.2.27 and OpenSSH 1.2.1 and
     earlier releases: sshd should not do the forwarding as root but
     as the user. Note that it has not been investigated if this could
     create other problems. This bug is a long-standing known bug,
     and also is due to the fact IDENT information was never supposed
     to be trusted anyway.
   - Put all ftponly and poponly users in specially identified groups with
        DenyGroups ftponly poponly
     This will fix the open-port-from-no-shell-user
   - Or lock the user in the system password database and use a special
     database for FTP and POP.
      
EXPLOIT
   Please do not request exploit from the listed authors. Requests for
   exploits will be ignored. A working exploit exists and has been
   tested on current Linux distributions. It is possible that an
   exploit be posted some time in the future (or that someone reads
   this and does it by himself ...).

NOTES
   This advisory is for information only. No warranty either expressed
   or implied. Full disclosure and dissemination are allowed as long as
   this advisory is published in full. No responsability will be taken
   from abuse or lack of use of the information in this advisory.





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10001251128120.14396-100000>