Xref: utzoo comp.unix.wizards:25679 alt.security:2577
Path: utzoo!utgpu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!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 3: How to Fix It
Message-ID: <3690:May1921:22:5191@kramden.acf.nyu.edu>
Date: 19 May 91 21:22:51 GMT
References: <19309@rpp386.cactus.org> <23893:May1901:19:2191@kramden.acf.nyu.edu> <19313@rpp386.cactus.org>
Organization: IR
Lines: 113

This article includes a series of diagrams showing how I think hardwired
ttys should work. This has all been explained before, both in my pty
paper and in Steve Bellovin's session manager paper, but John refuses to
accept the fact that dynamically allocated ttys are secure. So here goes.

In article <19313@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
> In article <23893:May1901:19:2191@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >(What I actually suggested is that SAK disconnect the current session.
> >This means that the user can later log in again and reconnect, resuming
> >work where he left off. For further details on session management, see
> >my pty paper, Bellovin's session manager paper, or VMS documentation.)
> [ I was going to respond to the other article from Dan.  I'm on a
>   "responding to Dan" diet ...  This last paragraph was too juicy to
>   pass up. ]
> Which means that your SAK scheme is actually less secure than I had
> originally thought.  What are you going to do to revoke TTY access to
> a process that =somehow= has illicitly gained access to the TTY?

``What are you going to do to revoke pipe access to a process that
=somehow= has illicitly gained access to the pipe?'' You don't do
anything. You create the pipe dynamically, and there is absolutely no
way that another process is going to have access to it.

I'm getting sick of explaining this to you again and again. So let me
draw you a picture of what the system looks like after suggestion #24:
                ___
     /^\       |abc|
     | <)      |def|
     | -  ---- |ghi| ---- /dev/tty00 ---- getty ---- /dev/ptyq7 ---- sh
     \_/       |___|
                          hardwired       system      pseudo-        user
    John      terminal      device        process       tty         process

Here getty never lets a user program access /dev/tty00; it forwards all
I/O through a pseudo-tty. Let's say you start a Trojan Horse:
                ___
     /^\       |abc|
     | <)      |def|
     | -  ---- |ghi| ---- /dev/tty00 ---- getty ---- /dev/ptyq7 ---- TROJAN
     \_/       |___|
                          hardwired       system      pseudo-        user
    John      terminal      device        process       tty         process

Now you leave the terminal alone, and another user comes along.
                ___
     /^\       |abc|
     | <       |def|
     | |  ---- |ghi| ---- /dev/tty00 ---- getty ---- /dev/ptyq7 ---- TROJAN
     \_/       |___|
                          hardwired       system      pseudo-        user
    Sally     terminal      device        process       tty         process

Sally bangs on ^K a few times. As I explained before, getty notices the
SAK and disconnects the current session:
                ___
     /^\       |abc|
     | <       |def|
     | |  ---- |ghi| ---- /dev/tty00 ---- getty    
     \_/       |___|
                          hardwired       system     
    Sally     terminal      device        process      


                                                   /dev/ptyq7 ---- TROJAN
						
                                                     pseudo-        user
                                                       tty         process

Notice that the link between the terminal and the Trojan Horse has been
completely severed. No process has access to /dev/tty00 other than
getty. Now Sally logs in, on an unused pseudo-tty allocated by getty:
                ___
     /^\       |abc|
     | <       |def|
     | |  ---- |ghi| ---- /dev/tty00 ---- getty ---- /dev/ptysb ---- login
     \_/       |___|
                          hardwired       system      pseudo-        safe
    Sally     terminal      device        process       tty         process


                                                   /dev/ptyq7 ---- TROJAN
						
                                                     pseudo-        user
                                                       tty         process

Your fake login program is still running, but it's inside a session that
Sally isn't talking to. Sally is talking to /dev/ptysb, which is
guaranteed clean. I explained in detail in a previous article why my
solution makes that guarantee.

Now do you understand why allocating an unused tty stops Trojans?

> Your scam lets the trojan or whatever lurk about in
> the background, and never kills it because you've been too kind hearted
> and let it live.

You have no idea what you are talking about.

> But
> what if /etc/getty isn't running?

Under my proposal, no I/O will happen at all if getty isn't talking to
the port. Note that all hardwired ttys are only accessible to root.

> All I want to know is what do you do to get rid of trojan horses after
> they have gained access to your tty line.  Could you please answer
> that one simple little question?

Can you please stop repeating the same stupid little question? If you
can't understand Bellovin's explanations or my explanations or the
series of diagrams above, I give up.

---Dan