NAME ptylogin AUTHOR Marc SCHAEFER <schaeferat_private> 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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:31:55 PDT