shell-modem-access.txt

`Date: Wed, 27 Jan 1999 09:01:51 +0100  
From: Marc SCHAEFER <[email protected]>  
To: [email protected]  
Subject: UNIX shell modem access vulnerabilities  
  
NAME  
ptylogin  
AUTHOR  
Marc SCHAEFER <[email protected]>  
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.  
  
`