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>
index | next in thread | raw e-mail
>[ 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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509160507.PAA10195>