[375] in linux-security and linux-alert archive
Re: Problem with /dev/ttyp*
daemon@ATHENA.MIT.EDU (Adrian Miranda)
Wed Sep 20 16:05:59 1995
Date: Wed, 20 Sep 95 11:38 PDT
From: ade@vancouver.wsu.edu (Adrian Miranda)
To: pfnguyen@netcom.com
CC: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.LNX.3.91.950919152556.4719A-100000@Viet.Viet.COM>
Reply-To: Adrian Miranda <ade@psg.com>
Perry F. Nguyen writes:
> On Tue, 19 Sep 1995, Joe Portman wrote:
>
> > I just discovered a user sniffing passwords by doing the following on
> > my system.
> > Kernel 1.2.11
>
> > cat /dev/ttyp? &
>
> > It does not work every time, but occasionally it captures the login name
> > and password of a careless user. It also prevents telnet logins on that
> > ptyp/ttyp pair.
>
> > 1. Is this a known bug? If so, how to fix it.
>
> This is a known security problem in all Unix's.
I once heard that System V style pseudo ttys are more secure, anyone
know if that is true?
> > 2. If not, can you think of a workaround. I tried removing read permissions
> > from the tty[p-s] series, but they come back after a telnet session exits.
> The only effective way I've found to prevent this from happening is to
> rewrite /bin/login to chmod() the tty to mode 600 before reading the
> username/password and then chowning the tty to the owner.tty and then
> mode 620.
I don't think this will work if the rogue process already has the tty
open before you do the chmod. An "fuser -k" on the device after you
do the chmod seems to be pretty effective, though probably not
perfect. Actually, doing an "fuser -k" seems particularly useful on
Linux, since Linux seems highly prone to leaving processes lying
around on ptys after someone logs out, especially if their session
ends in an abnormal fashion. I think I've seen this on most/all Unix
systems, but Linux seems worse, perhaps because (I'm told) it only
sends a SIGHUP to the process group leader when someone disconnects
unexpectedly.
Adrian
