From owner-freebsd-security Sun Sep 10 05:17:32 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA20064 for security-outgoing; Sun, 10 Sep 1995 05:17:32 -0700 Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA20058 for ; Sun, 10 Sep 1995 05:17:26 -0700 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id PAA09904 for security@freebsd.org; Sun, 10 Sep 1995 15:18:31 +0300 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.6.9) with ESMTP id OAA01367 for ; Sun, 10 Sep 1995 14:16:23 +0300 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.6.9) id OAA03773; Sun, 10 Sep 1995 14:16:22 +0300 From: "Andrew V. Stesin" Message-Id: <199509101116.OAA03773@office.elvisti.kiev.ua> Subject: Re: Do we *really* need logger(1)? To: pst@shockwave.com (Paul Traina) Date: Sun, 10 Sep 1995 14:16:22 +0300 (EET DST) Cc: security@freebsd.org In-Reply-To: <199509081538.IAA02968@precipice.shockwave.com> from "Paul Traina" at Sep 8, 95 08:38:10 am X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Content-Length: 1133 Sender: security-owner@freebsd.org Precedence: bulk Dear Paul, # Comments? # # no, no, No, NO.....NO!!!!!!!!! # # Don't duplicate effort with half-assed schemes that make local assumptions. # # Don't confuse authentication with authorization. ^^^^^^^ intermix, better to say? # There are already kerberos patches available for syslogd to do the # right thing. Agreed, 100 hundred times agreed. This is The Best Solution (tm) because of many issues, like interoperability, design, etc... But: where is FreeBSD Kerberos port for us to use, for example, in Europe? The second. Does the kerberized version of syslog support any kind of fault-tolerant message delivery? (I don't know much about Kerberos stuff :( ) And we need a facility to do cross-host logging _today_, and for sensitive information, too. Please, I'll be very grateful if someone will give me a pointer to some ready-to-use solution. My own desire to rewrite syslogd+syslog() (means: to invent another incompatible bicycle with square wheels :) from scratch is not too strong. -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 From owner-freebsd-security Sun Sep 10 07:49:49 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA26296 for security-outgoing; Sun, 10 Sep 1995 07:49:49 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA26277 for ; Sun, 10 Sep 1995 07:49:45 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id QAA16039 ; Sun, 10 Sep 1995 16:49:43 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id QAA01085 ; Sun, 10 Sep 1995 16:49:42 +0200 Received: (from roberto@localhost) by keltia.Freenix.FR (8.7.Beta.14/keltia-uucp-2.4) id PAA19339; Sun, 10 Sep 1995 15:29:15 +0200 (MET DST) From: Ollivier Robert Message-Id: <199509101329.PAA19339@keltia.Freenix.FR> Subject: Re: Do we *really* need logger(1)? To: stesin@elvisti.kiev.ua (Andrew V. Stesin) Date: Sun, 10 Sep 1995 15:29:14 +0200 (MET DST) Cc: pst@shockwave.com, security@freebsd.org In-Reply-To: <199509101116.OAA03773@office.elvisti.kiev.ua> from "Andrew V. Stesin" at Sep 10, 95 02:16:22 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1083 X-Mailer: ELM [version 2.4 PL24 ME7a+] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: security-owner@freebsd.org Precedence: bulk It seems that Andrew V. Stesin said: > Agreed, 100 hundred times agreed. This is The Best Solution (tm) > because of many issues, like interoperability, design, etc... > But: where is FreeBSD Kerberos port for us to use, for example, > in Europe? Take the crypto stuff in South Africa (from the FAQ: South Africa skeleton.mikom.csir.co.za:/pub/FreeBSD storm.sea.uct.ac.za:/pub/FreeBSD it has all the eBones stuff. Alas it is Kerbv4 no eBones for Kerbv5 :-( -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.Freenix.FR 2.2-CURRENT #0: Sat Sep 9 17:49:09 MET DST 1995 From owner-freebsd-security Sun Sep 10 10:02:42 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA08454 for security-outgoing; Sun, 10 Sep 1995 10:02:42 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA08426 for ; Sun, 10 Sep 1995 10:02:39 -0700 Received: from sivka.carrier.kiev.ua (sivka.carrier.kiev.ua [193.125.68.130]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id KAA20037 for ; Sun, 10 Sep 1995 10:02:16 -0700 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id UAA19972 for security@freebsd.org; Sun, 10 Sep 1995 20:02:23 +0300 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.6.9) with ESMTP id TAA06944 for ; Sun, 10 Sep 1995 19:02:22 +0300 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.6.9) id TAA11404; Sun, 10 Sep 1995 19:02:20 +0300 From: "Andrew V. Stesin" Message-Id: <199509101602.TAA11404@office.elvisti.kiev.ua> Subject: Kerberized 'syslog' (was: Do we really need logger(1)? To: roberto@keltia.Freenix.FR (Ollivier Robert) Date: Sun, 10 Sep 1995 19:02:20 +0300 (EET DST) Cc: security@freebsd.org In-Reply-To: <199509101329.PAA19339@keltia.Freenix.FR> from "Ollivier Robert" at Sep 10, 95 03:29:14 pm X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Content-Length: 1047 Sender: security-owner@freebsd.org Precedence: bulk Dear Ollivier, # It seems that Andrew V. Stesin said: # > Agreed, 100 hundred times agreed. This is The Best Solution (tm) # > because of many issues, like interoperability, design, etc... # > But: where is FreeBSD Kerberos port for us to use, for example, # > in Europe? # # Take the crypto stuff in South Africa (from the FAQ: # # South Africa # skeleton.mikom.csir.co.za:/pub/FreeBSD # # storm.sea.uct.ac.za:/pub/FreeBSD # # it has all the eBones stuff. Alas it is Kerbv4 no eBones for Kerbv5 # :-( # AFAIK this stuff now is in process of integration into the tree, and the legal situation is far of a crystal clearness as well. Please, correct me if I'm wrong. And still no answer: any fault-tolerance features in Kerberized syslod yet? # -- # Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net # FreeBSD keltia.Freenix.FR 2.2-CURRENT #0: Sat Sep 9 17:49:09 MET DST 1995 # -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 From owner-freebsd-security Fri Sep 15 13:16:00 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA01907 for security-outgoing; Fri, 15 Sep 1995 13:16:00 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA01901 ; Fri, 15 Sep 1995 13:15:52 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA17249; Fri, 15 Sep 1995 14:18:06 -0600 Date: Fri, 15 Sep 1995 14:18:06 -0600 From: Nate Williams Message-Id: <199509152018.OAA17249@rocky.sri.MT.net> To: security@Freebsd.org, core@Freebsd.org Subject: forwarded message from Grant Haidinyak Sender: owner-security@Freebsd.org Precedence: bulk ------- start of forwarded message (RFC 934 encapsulation) ------- [ 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. ] From: Grant Haidinyak To: "Nate Williams" Cc: grant@iwv.com Subject: Re: PTY's reused to quickly Date: Fri, 15 Sep 1995 11:32:43 -0700 Nate, Actually, this one of the early bugs with BSD 4.2. I didn't want to post an article with a subject "HUGE Security Hole in FreeBSD, Watch Out!!!!!!". This tends to attract to much attention. 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. 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. If you want anymore information, let me know. grant ------- end ------- From owner-freebsd-security Fri Sep 15 13:25:00 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA02308 for security-outgoing; Fri, 15 Sep 1995 13:25:00 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA02303 ; Fri, 15 Sep 1995 13:24:56 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id NAA24367; Fri, 15 Sep 1995 13:24:35 -0700 Message-Id: <199509152024.NAA24367@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Nate Williams cc: security@Freebsd.org, core@Freebsd.org Subject: Re: forwarded message from Grant Haidinyak In-reply-to: Your message of "Fri, 15 Sep 1995 14:18:06 MDT." <199509152018.OAA17249@rocky.sri.MT.net> Date: Fri, 15 Sep 1995 13:24:35 -0700 From: "Justin T. Gibbs" Sender: owner-security@Freebsd.org Precedence: bulk I've complained about this behavior many times before, but no one even acknowledged it as a bug. :(. I've always seen it by acidently killing an xterm running a make world in an su'd shell. When I pop up another xterm as user gibbs, I see the output from the make world still... and get some kind of funky mixture of the new shell and old shell responding to my input. >------- start of forwarded message (RFC 934 encapsulation) ------- >[ 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. ] > >From: Grant Haidinyak >To: "Nate Williams" >Cc: grant@iwv.com >Subject: Re: PTY's reused to quickly >Date: Fri, 15 Sep 1995 11:32:43 -0700 > >Nate, > >Actually, this one of the early bugs with BSD 4.2. I didn't want to >post an article with a subject "HUGE Security Hole in FreeBSD, Watch >Out!!!!!!". This tends to attract to much attention. > >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. > >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. > >If you want anymore information, let me know. > > >grant >------- end ------- -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-security Fri Sep 15 16:15:47 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA13920 for security-outgoing; Fri, 15 Sep 1995 16:15:47 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA13915 ; Fri, 15 Sep 1995 16:15:44 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA11897; Fri, 15 Sep 1995 16:14:47 -0700 To: Nate Williams cc: security@Freebsd.org, core@Freebsd.org Subject: Re: forwarded message from Grant Haidinyak In-reply-to: Your message of "Fri, 15 Sep 1995 14:18:06 MDT." <199509152018.OAA17249@rocky.sri.MT.net> Date: Fri, 15 Sep 1995 16:14:47 -0700 Message-ID: <11895.811206887@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@Freebsd.org Precedence: bulk > ------- start of forwarded message (RFC 934 encapsulation) ------- > [ 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. ] I have experienced this occasionally as well, but going back for quite some time, too! Jordan From owner-freebsd-security Fri Sep 15 22:11:41 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA28891 for security-outgoing; Fri, 15 Sep 1995 22:11:41 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA28884 ; Fri, 15 Sep 1995 22:11:26 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA10195; Sat, 16 Sep 1995 15:07:25 +1000 Date: Sat, 16 Sep 1995 15:07:25 +1000 From: Bruce Evans Message-Id: <199509160507.PAA10195@godzilla.zeta.org.au> To: core@freebsd.org, nate@rocky.sri.MT.net, security@freebsd.org Subject: Re: forwarded message from Grant Haidinyak Sender: owner-security@freebsd.org Precedence: bulk >[ 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 From owner-freebsd-security Sat Sep 16 01:00:11 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA04748 for security-outgoing; Sat, 16 Sep 1995 01:00:11 -0700 Received: from strider.ibenet.it (root@[194.179.130.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA04698 ; Sat, 16 Sep 1995 00:59:53 -0700 Received: (from piero@localhost) by strider.ibenet.it (8.6.12/8.6.12) id KAA05308; Sat, 16 Sep 1995 10:00:26 +0200 From: Piero Serini Message-Id: <199509160800.KAA05308@strider.ibenet.it> Subject: Re: forwarded message from Grant Haidinyak To: nate@rocky.sri.MT.net (Nate Williams) Date: Sat, 16 Sep 1995 10:00:25 +0200 (MET DST) Cc: security@Freebsd.org, core@Freebsd.org In-Reply-To: <199509152018.OAA17249@rocky.sri.MT.net> from "Nate Williams" at Sep 15, 95 02:18:06 pm Reply-To: piero@strider.ibenet.it Operating-System: FreeBSD 1.1.5.1 X-Phone-Number: +39 (2) 58113562 X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 896 Sender: owner-security@Freebsd.org Precedence: bulk Hello. Quoting from Nate Williams (Fri Sep 15 22:18:06 1995): > [ 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. ] ... Yes it is. It was so in 2.0.0-SNAP950322, and was reported at least 4 months ago. It can be repeated by (on 2.0.0-SNAP): - login - startx - run 'su' and an xterm from there - write down the pty # - hit ctrl-alt-delete - from another machine, telnet into yours until your pty is = the one you wrote down - play with the root shell. Even comands go the the root shell, odd ones to yours I think. Bye, -- # $Id: .signature,v 1.12 1995/08/14 12:10:54 piero Exp $ Piero Serini Via Giambologna, 1 I 20136 Milano - ITALY From owner-freebsd-security Sat Sep 16 03:30:20 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA14336 for security-outgoing; Sat, 16 Sep 1995 03:30:20 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA14250 ; Sat, 16 Sep 1995 03:30:01 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA21872; Sat, 16 Sep 1995 20:24:11 +1000 Date: Sat, 16 Sep 1995 20:24:11 +1000 From: Bruce Evans Message-Id: <199509161024.UAA21872@godzilla.zeta.org.au> To: nate@rocky.sri.MT.net, piero@strider.ibenet.it Subject: Re: forwarded message from Grant Haidinyak Cc: core@Freebsd.org, security@Freebsd.org Sender: owner-security@Freebsd.org Precedence: bulk >> [ 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. ] >... >Yes it is. It was so in 2.0.0-SNAP950322, and was reported at >least 4 months ago. It can be repeated by (on 2.0.0-SNAP): Try this fix. Closing the pty master cleared the tty's session pointer, but this pointer must be kept around until the controlling terminal (the pty slave) is last-closed. The bug has existed for many years. --- *** /sys/kern/tty_pty.c~ Sat Sep 9 06:44:41 1995 --- /sys/kern/tty_pty.c Sat Sep 16 18:26:13 1995 *************** *** 323,327 **** tp->t_oproc = 0; /* mark closed */ - tp->t_session = 0; return (0); } --- 324,327 ---- --- There are several other bugs or at best inconsistencies in closing the controlling terminal. (1) if the controlling terminal is last-closed in spec_close(), then the process group is not sent a SIGHUP when the session leader exits. This only matters in weird circumstances (perhaps never?): the process group must have other processes in it; these processes must have closed all there fd's for the controlling terminal; and orphanpg() must not have sent the SIGHUP for other reasons. Last-closing of the controlling terminal in spec_close() was introduced in 4.4lite. A hack is involved. Normally and previously, controlling terminals could never go away until the session leader exits, because the session leader holds a reference to the terminal so the last close() from user space was never the last-close. (2) if the controlling terminal is last-closed in spec_close(), then the the driver waits for output to drain iff FNONBLOCK is set in the file flags, but if the controlling terminal is last-closed in exit1(), then the exit1() calls ttywait() to always wait for output to drain before it (indirectly) calls vclean() which calls the driver close with FNONBLOCK set so that the driver doesn't wait again (there may be more output, e.g., echos). I may have broken this by honoring the FNONBLOCK flag. In 4.4lite, vclean() passed IO_NDELAY, the driver checked IO_NDELAY, but spec_close() passed the file flags, where the IO_NDELAY bit corresponds to O_SHLOCK; thus the driver waited for output to drain iff O_SHLOCK was clear; I think O_SHLOCK never gets set in the file flags so the driver always waited for output to drain. Always waiting seems to be required by POSIX, although it is wrong. If waiting is required then it should be atomic with closing. Bruce From owner-freebsd-security Sat Sep 16 11:37:15 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24222 for security-outgoing; Sat, 16 Sep 1995 11:37:15 -0700 Received: from hermes.sees.bangor.ac.uk (hermes.sees.bangor.ac.uk [147.143.102.8]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA24202 for ; Sat, 16 Sep 1995 11:37:12 -0700 From: Mr D Whitehead (Ext 2703) Message-Id: <24764.9509161835@hermes.sees.bangor.ac.uk> Received: from adam.sees (adam.sees.bangor.ac.uk) by hermes.sees.bangor.ac.uk; Sat, 16 Sep 95 19:35:10 BST Subject: Re: forwarded message from Grant Haidinyak To: security@freebsd.org Date: Sat, 16 Sep 1995 19:35:09 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2190 Sender: owner-security@freebsd.org Precedence: bulk > Quoting from Nate Williams (Fri Sep 15 22:18:06 1995): > > [ 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. ] > ... > > Yes it is. It was so in 2.0.0-SNAP950322, and was reported at > least 4 months ago. It can be repeated by (on 2.0.0-SNAP): > - login > - startx > - run 'su' and an xterm from there > - write down the pty # > - hit ctrl-alt-delete > - from another machine, telnet into yours until your pty is = the > one you wrote down > - play with the root shell. Even comands go the the root shell, > odd ones to yours I think. This bug (or at least one very much like it) has been around since at least BSD4.3 . We first saw it here on a VAX750 running BSD4.3, and still see it (occasionally) on our Suns (4.1.x). The common factor in most cases we have looked at seems to be the way in which the pty connection is (broken) terminated. Typically the connection was to a PC running PC TCP-IP, eXceedp or similar software, and the session was abrutly terminated by either the PC being switched off or the PC getting itself into a mess and hanging up. One case however was different, the user was using a PC with software similar to PC TCP-IP. He would logout correctly but would get a message indicating that the /etc/utmp file could not be written to. Changing the protection of /etc/utmp from 644 to 666 would get rid of the message and the shell. We banned to software but did not get to the bottom of the problem. -- Dave Whitehead (Computer Support Staff) ------------------------------------------------------------------------------- EMAIL:- | TELEPHONE (work):- (work) davew@sees.bangor.ac.uk | +44 1248 382703 (Direct line) (home) 100023.1076@compuserve.com | +44 1248 351151 ext 2703 ------------------------------------------------------------------------------- SNAIL MAIL:- Dave Whitehead School of Electronic Engineering & Computer Systems, University College of North Wales, Dean Street, Bangor LL57 1UT ------------------------------------------------------------------------------