For mgetty users with non-trusted shell logins

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

This announcement is for the enjoyment of mgetty users only :)
I sent it to the major distributions yesterday, and I will
send it to bug-traq tomorrow.  Theoretically it's non disclosure
till 27/01/1999 23:59 (what timezone ? :)).

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.5 1999/01/25 08:34:21 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.

   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.

   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.

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.

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 from
   27/01/1999 23:59 and 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.