Date: Sat, 16 Sep 1995 15:07:25 +1000 From: Bruce Evans <bde@zeta.org.au> To: core@freebsd.org, nate@rocky.sri.MT.net, security@freebsd.org Subject: Re: forwarded message from Grant Haidinyak Message-ID: <199509160507.PAA10195@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>[ Quick background. Grant has been experiencing a bug whereby folks are >re-connected to login which were abruptly dis-connected from a machine. >This is a *HUGE* security hole if it is indeed true. ] This problem has probably been reduced by the "zombie" tty state in 2.2-current and recently in 2.1-stable. >Anywho, here's my environment, and the symptoms I'm seeing. >1) A box running FreeBSD 2.0.5 Release (off the cdrom). This box is > named "cow" > a 16 port Boca serial card/box. > 10 Development computers hooked up to the Boca board. > >2) People rlogin into cow, then tip into one of the development > systems, do their work, then when they finish, they type ~. to > exit from the tip session. Unfortunatly, these characters are > intercepted by the rlogin, which drops the login session before > the tip session is killed. Then when someone else rlogins, it > seems like the old pty is selected, instead of a new one, because > the output of the new session and the old session are > intermingled and the input seems to alternate between the two > sessions. Under 2.2-current, I see the following behaviour: a) rlogin twice, then look at pty and process states using `pstat -t' and `ps laxw'. Everything is normal. Only two ptys are in use, ttyp0 and ttyp1 (it's a lightly used system) and their states are both `OCc' (Open, Carrier, connected); there are two rlogind's without a controlling terminal and a shell on each of the ptys. b) Run `cu -l /dev/cuaa0' on ttyp1. Look at pstat and ps output again on ttyp0. Now cuaa0 is in state `OCc' too and there are two `cu' processes on ttyp1. c) Attempt to exit from cu using `~.' (actually exit from one of the rlogind's). Look at pstat and ps output again on ttyp0. Everything on ttyp1 has died except for one `cu' whoes controlling terminal has been revoked. Somehow the revocation hasn't completely reached ttyp1 - it has state `OZ' (Open, Zombie). The Zombie state stops further i/o on the pty (unless CLOCAL is toggled). d1) Look at pstat and ps output a little later. The dying `cu' goes away after 2-3 seconds. There should be no problems after that. d2) rlogin again before the `cu' has gone away. The `cu' still takes 2-3 seconds to go away. This shouldn't cause any problems because the `cu's controlling terminal has been revoked, but it's hard to be sure without doing i/o (my cuaa0 wasn't connected to anything). ttyp1 gets used. This is bad. Apparently the zombie flag is being cleared somewhere. >My speculation is that when the rlogin session goes away, it doesn't >clean up the session correctly, which causes the pty to stay active, >then when a new pty needs to be picked for a new rlogin session, the >login task (rlogind) picks the next pty in the line, not knowing >that the session wasn't cleaned up completely. The process group leader (a shell) exits correctly, so a SIGHUP should be sent to `cu' and `cu's controlling terminal should be revoked. This apparently works correctly. Apparently `cu' ignores SIGHUPS at least for a little while. Or perhaps `cu' exits when it reads EOF. This leaves to points to explain: 1) why doesn't revoking the control terminal work for you? 2) why doesn't the pty get closed when the controlling terminal is revoked? After I started looking at things using ddb and fstat in addition to pstat and ps, rlogging in while `cu' was still active started to hang and once the connection was refused. I would expect this behaviour if rlogind picks a zombie tty, but it didn't happen at first. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509160507.PAA10195>