COMMAND

    ssh

SYSTEMS AFFECTED

    munices

PROBLEM

    Marc Schaefer found following.  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.

    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).

    However it's  much more  accurate (not  to mention  secure) to use
    'AllowGroups' rather than DenyGroups. If AllowGroups is set,  then
    only if a users primary  group matches one of the  specified group
    names are they permitted to complete a connection attempt.

    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).

    The real issue  is however the  common misconception that  setting
    /bin/false to  a user  shell to  prevent it  to login  while still
    allowing reading POP  mail and FTP  is enough to  prevent the user
    from issuing local-issued connections to services.  The impact  is
    clear:   bypassing firewalling,  or hosts.deny.   Additionnally it
    will create fake IDENT (but that's a ssh feature, it seems).

SOLUTION

    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.

    So, what about fix?  Well:

        - 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.