COMMAND

    ptylogin

SYSTEMS AFFECTED

    Most unices are probably concerned by this problem

PROBLEM

    Marc  Schaefer  found  following.   It's  about  denial of service
    and/or  security  (reading  passwords,  using  modems to dial out)
    vulnerability.  If a user has access to the modem tty when dialing
    into a UNIX system, such as having a shell account and logging  in
    from modem, there are the following problems:

    - the user  can lock out  that modem, preventing  further log-ins,
      even without paying for the communication (ie after hangup),
    - the  user  can  dial  out  with  that  modem, even with  correct
      permissions,
    - even  with  correct  permissions,  the user can impersonate  the
      login and get passwords.

    This  works  even  if  the  user  has  no write access to the lock
    directory, and even if the  modem has the ``+++'' escape  sequence
    disabled  (not  having  it  disabled,  through ATS2=255 or similar
    command,  might  make  your  system  *vulnerable*  even *with* the
    work-around  shown  below).    An  additionnal   modem-reliability
    suggestion (which still doesn't make the attack impossible) is  to
    make  sure  that  DTR  drop  hangups  the  connection.  For a more
    complete explanation  of the  problem, please  look in  the mgetty
    package for documentation (contrib/ptylogin).  Tested ptylogin:

        $Id: ANNOUNCEMENT,v 1.7 1999/01/27 08:00:28 schaefer Exp $

    A working  exploit exists  and has  been tested  on current  Linux
    distributions. It is possible that an exploit will be posted  some
    time in the future.  Having mgetty or not as a modem getty doesn't
    make the attack  impossible. Having mgetty,  might, in some  case,
    make the attack more difficult.

SOLUTION

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

    - you do not have modems,
    - you do not have untrusted shell account users which may want  to
      DoS you or use your modems to dial out,
    - you use  the rlogin work-around  noted below and  user nobody is
      not equivalent (rhost ``security''),
    - your OS has a root-reopen-only-on-unmaskable-hangup  comportment
      (none at this time to my knowledge),
    - you use the ptylogin work-around available in mgetty-1.1.20,
    - you provide  login access through  modems connected to  terminal
      server (provided the terminal server is immune itself because it
      never offers  a shell  to untrusted  people and  breaks the  TCP
      connection  on  any  modem  hangup,  ie  does not offer standard
      dial-out  capabilities,  in  summary  is  a rlogin-workaround in
      itself).

    A work-around for  the DoS and  the security problem  exists.  You
    have  two  options.   Either  you  use  the mgetty-1.1.20 provided
    ``ptylogin'' program  as login  program, or  you use  rlogin.  You
    then update mgetty's login.config.

    Example 1 (using ptylogin)

        *       root    dialin  /usr/bin/ptylogin @

    Exemple 2 (using rlogin)

        *       nobody  dialin  /usr/bin/rlogin -8E localhost -l @

    Please check that if you enter nobody as user name, you don't  get
    a shell.  This  could happen if nobody  has a shell and  localhost
    is listed in ~nobody/.rhosts or /etc/hosts.equiv.  The work-around
    works  as  long  as  there  is  no other specific configuration in
    login.config  (AutoPPP  and  FIDO  are  ok;  user  specific  login
    commands  are  NOT,  unless  the  login  program refuses user name
    switch,  ie  doesn't  retry  on  failure).   There  is  no   known
    work-around for other gettys than mgetty at this time.

    The security  problems can  be fixed  in changing  the kernel  and
    getty  login  program  (such  as  mgetty).   The denial of service
    problem  cannot  be  fixed;  however  it can be worked-around with
    idled(8)  or  the  described  ptylogin(1) or rlogin(1) work-around
    above.  The  change would be  to add fcntl  flags on a  tty, which
    would be ``allow reopen of  this tty only by root  after hangup'',
    in addition to ``immutable hangup causes no further access through
    open fd''.  At the end, see:

        http://www.research.att.com/~smb/papers/sessext.ps (or .pdf)