Xref: utzoo comp.unix.wizards:25365 alt.security:2418
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: BSD tty security, part 4: What You Can Look Forward To
Message-ID: <27845:May315:35:3491@kramden.acf.nyu.edu>
Date: 3 May 91 15:35:34 GMT
References: <721@seqp4.UUCP> <11974: May214:00:3691@kramden.acf.nyu.edu> <1991May2.202847.15537@wpi.WPI.EDU>
Organization: IR
Lines: 29

In article <1991May2.202847.15537@wpi.WPI.EDU> entropy@wpi.WPI.EDU (Lawrence C Foard) writes:
>One other possible attack occurs to me, and I don't think the fixs I have seen
>posted would prevent it:
>1) Make an unused tty device into your controlling terminal, 
>2) Close it. 
>3) You currently have no open files.
>4) Wait for a victim to log in on the tty, open /dev/tty and use TIOCSTI on it.

My fixes stop this attack in three ways. First, by closing all open
files you prevent yourself from reopening the new /dev/tty. Technically,
you still do have the same controlling terminal (p_ttyd), but you can't
abuse that fact as the old /dev/tty driver is no longer accessible.
That's the point of replacing /dev/tty.

Second, you can't ``make an unused tty device into your controlling
terminal'' by opening an unused tty device, because all unused tty
devices are world-inaccessible. That's the point of protecting the files
and making the tty-handling programs setuid pty.

Third, you can't ``make an unused tty device into your controlling
terminal'' by waiting for your ctty to become unused, because the
tty-handling process keeps the master side open until nobody has the
slave side open. That's the point of TIOCOPENCT. Note that without the
new /dev/tty this protection would not be effective.

There are more sophisticated attacks that are only stopped by one of
these three measures.

---Dan