[LWN Logo]

Date:	Wed, 27 Jan 1999 09:01:51 +0100
From:	Marc SCHAEFER <schaefer@ALPHANET.CH>
Subject:      UNIX shell modem access vulnerabilities
To:	BUGTRAQ@NETSPACE.ORG

NAME
   ptylogin
AUTHOR
   Marc SCHAEFER <schaefer@alphanet.ch>
      with the help of the author of mgetty, Gert DOERING, and Theodore Y TSO.
VERSION
   $Id: ANNOUNCEMENT,v 1.7 1999/01/27 08:00:28 schaefer Exp $

ABSTRACT
   Denial of Service and/or security (reading passwords, using
   modems to dial out) vulnerability.

IMPACT
   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).
          (Denial of Service attack)

      - the user can dial out with that modem, even with correct permissions.
          (Security)

      - even with correct permissions, the user can impersonate the login
        and get passwords.
          (Security)

   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)

IMMUNE CONFIGURATIONS
   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)

   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.

OPERATING SYSTEMS
   Most UNIX systems are probably concerned by this problem

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

WORK-AROUND
   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 @

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

   Note that none of the ptys (if using ptylogin) nor the network
   ttys (which are usually ptys too) should be made secure in the
   sense of /etc/securetty or login.defaults, except if you want to
   enable root logins.

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

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.
   More details on the problem and the work-arounds or solution are
   contained in the mgetty documentation. No responsability will be
   taken from abuse or lack of use of the information in this advisory.