telnet to a certain machine logs me out

telnet to a certain machine logs me out

Post by Benny Cla » Fri, 07 Feb 1992 23:08:47



When I telnet to a certain machine on my network, I
am prompted for a username and password, but after
that I get logged out automatically.  I have checked
the obvious stuff like my .login and .cshrc.

I am running SunOS 4.1

Any ideas?
Please email me.

Thanks,

--
   _/             Benny Clark                  Phone : 919-859-4004
      __ /  ___/ CAD Systems of Carolina       Fax   : 919-859-0657

_/ ____/ ____/ Raleigh, NC  27606                    : ...!uunet!csoc!ice

 
 
 

telnet to a certain machine logs me out

Post by Elizabeth Schwar » Sat, 08 Feb 1992 06:29:09


   When I telnet to a certain machine on my network, I
   am prompted for a username and password, but after
   that I get logged out automatically.  I have checked
   the obvious stuff like my .login and .cshrc.

   I am running SunOS 4.1
---
Our Sun's have been doing that. We have been interpreting it as a sign
that it is time to reboot the host in question.
  If you come up with a less drastic solution, please post it!
thanks, Betsy
--


U-Mass Boston  Computer Science Dept. Staccato signals
Harbor Campus  Boston, MA 02125-3393         of constant information...

 
 
 

telnet to a certain machine logs me out

Post by Richard J. Nizi » Sat, 08 Feb 1992 21:57:07



>When I telnet to a certain machine on my network, I
>am prompted for a username and password, but after
>that I get logged out automatically.  I have checked
>the obvious stuff like my .login and .cshrc.

>I am running SunOS 4.1

>Any ideas?
>Please email me.

>Thanks,

>--
>   _/             Benny Clark                  Phone : 919-859-4004
>      __ /  ___/ CAD Systems of Carolina       Fax   : 919-859-0657

>_/ ____/ ____/ Raleigh, NC  27606                    : ...!uunet!csoc!ice

I had the same problem.... What I found out was that my $HOME was not
mounted on that specific client, thus, access was denied.. Hope this
helps.

Rick Niziak
UNIX Systems Coordinator
Allen-Bradley Company, Inc
.

 
 
 

telnet to a certain machine logs me out

Post by Duncan McEw » Wed, 12 Feb 1992 09:01:56



(Elizabeth Schwartz) writes:

(Benny Clark) writes:

>   When I telnet to a certain machine on my network, I
>   am prompted for a username and password, but after
>   that I get logged out automatically.

>Our Sun's have been doing that. We have been interpreting it as a sign
>that it is time to reboot the host in question.
>If you come up with a less drastic solution, please post it!

One situation where I have seen this happen is if there is an orphaned
process still running on the slave pty left over from some previous session.
I think what happens is that telnetd (and rlogind) searches for the first
free master pty, starts a new login process on the coresponsing slave side,
but then the new shell fails to properly access its slave terminal because the
orphaned process still has it open.

When I have encountered this, killing the orphaned process corrects the
situation.  As to why there is an orphaned process at all -- I wouldn't
have a clue...

Duncan

 
 
 

telnet to a certain machine logs me out

Post by Duncan McEw » Wed, 12 Feb 1992 09:19:26



(Elizabeth Schwartz) writes:

(Benny Clark) writes:

>   When I telnet to a certain machine on my network, I
>   am prompted for a username and password, but after
>   that I get logged out automatically.

>Our Sun's have been doing that. We have been interpreting it as a sign
>that it is time to reboot the host in question.
>If you come up with a less drastic solution, please post it!

One situation where I have seen this happen is if there is an orphaned
process still running on the slave pty left over from some previous session.
I think what happens is that telnetd (and rlogind) searches for the first
free master pty, starts a new login process on the coresponsing slave side,
but then the new shell fails to properly access its slave terminal because the
orphaned process still has it open.

When I have encountered this, killing the orphaned process corrects the
situation.  As to why there is an orphaned process at all -- I wouldn't
have a clue...

Duncan

 
 
 

telnet to a certain machine logs me out

Post by Steve Sean » Wed, 12 Feb 1992 10:43:23


We have the same problem.  To make it more interesting, the ftp
problem only occurs from machines not in the /etc/hosts file.

Any ideas?

Steve

--

******************************  303 Mechanical Engineering                    
  608 / 262-7463             *  1513 University Avenue                        
  608 / 256-4730             *  Madison, Wisconsin  53706                    

 
 
 

telnet to a certain machine logs me out

Post by tad » Wed, 12 Feb 1992 07:39:33



(Duncan McEwan) writes:

> (Elizabeth Schwartz) writes:

> (Benny Clark) writes:

> >   When I telnet to a certain machine on my network, I
> >   am prompted for a username and password, but after
> >   that I get logged out automatically.

> >Our Sun's have been doing that. We have been interpreting it as a sign
> >that it is time to reboot the host in question.
> >If you come up with a less drastic solution, please post it!

> One situation where I have seen this happen is if there is an orphaned
> process still running on the slave pty left over from some previous session.
> I think what happens is that telnetd (and rlogind) searches for the first
> free master pty, starts a new login process on the coresponsing slave side,
> but then the new shell fails to properly access its slave terminal because the
> orphaned process still has it open.

Actually, it goes something like this: telnetd picks a pty pair that
happens to have an orphaned process active on it (ie. therefore the
session groups or process groups belong to that orphaned process).
telnetd fork()/exec()'s your login shell. If your login shell is sh --
you are ok.  If your login shell is csh you get screwed -- csh tries
to change the process or session group to become a "leader" and since
there already is a process group active on the pty, this fails and csh
either dies silently or gets something like a SIGTTOU.

I might have some of the terminology wrong, but that's what I saw....

This does not happen with rlogin. I've seen the source to sunos4.1
rlogind, and Sun inserted a kludge in rlogind to deal with EXACTLY
this problem.  When their code goes to allocate a pty pair, they do a
ioctl(TIOCSPGRP) (to change the process group, ie. a test) and if this
returns an error, rlogind goes and picks another pty pair.

I modified the pty allocation code in telnetd likewise (and in GNU
emacs, and in script, etc...), and the problem vanished. Perhaps Sun
has a patch for this problem (I doubt it). Maybe 4.1.2 fixes it.

Quote:> When I have encountered this, killing the orphaned process corrects the
> situation.  As to why there is an orphaned process at all -- I wouldn't
> have a clue...

Because vhangup(), process groups, and session groups are broken. And
that's as good a leadin as I can possibly think of for Dan. :-)
 <tdr.
 
 
 

telnet to a certain machine logs me out

Post by Charles H. Buchhol » Thu, 13 Feb 1992 01:26:07



>I modified the pty allocation code in telnetd likewise (and in GNU
>emacs, and in script, etc...), and the problem vanished. Perhaps Sun
>has a patch for this problem (I doubt it). Maybe 4.1.2 fixes it.

4.1.2 does *not* fix it.  I have a new patch (100125-05), which I
haven't tried yet.  Note the -05; Sun has been batting this one around
for a while.  100125-05 is a new in.telnetd, which just missed 4.1.2.

I'll try to remember to post results after I've tried the new patch.


Systems Programmer                             (215) 898-2491
School of Engineering and Applied Science      200 S. 33rd St, rm 154
University of Pennsylvania                     Philadelphia, PA 19104

 
 
 

telnet to a certain machine logs me out

Post by Dan Bernste » Thu, 13 Feb 1992 19:49:12



> Because vhangup(), process groups, and session groups are broken. And
> that's as good a leadin as I can possibly think of for Dan. :-)

Yep, it's pretty reliable. :-) To break UNIX security, a system cracker
attacks two things: (1) privileged programs; (2) process communication.
The more privileged programs you have and the more complex they are, the
better the chance that they'll have security holes. Similarly, the more
ways you introduce for processes to affect each other, the better the
chance that one of those ways can be abused. It's perhaps not too
surprising that the UNIX-style systems regarded as ``clean'' and secure
are exactly those for which you can make complete lists of (1) and (2)
and honestly say that the lists are _short_.

The way that UNIX ttys have always been handled is a disaster by these
criteria. I/O-generated tty signals and tty-generated signals are two
new and uncontrolled forms of process communication. As for tty I/O,
filesystem protections aren't used at all: any user can get access to
the actual physical tty devices and, under BSD, to the small static set
of pseudo-tty devices. Any file which is shared among users but which
can be affected by a single user is a recipe for disaster: there's no
reason a priori that an attacker can't take complete control over such a
file. Furthermore, processes communicate with ttys not only via file
descriptors, but by /dev/tty (u_ttyd or p_ttyd in struct proc on most
systems), which is the root of a devastating set of security holes
because it doesn't have any protection. It's a real shame that /dev/tty
wasn't instead handled with a TTY environment variable.

BSD introduced vhangup(), which supposedly added tty security by
revoking access to a given tty device. (Let's ignore the fact that if
you can vhangup() a process, then it can vhangup() you---yet another
method of process communication, hence another problem.) On many BSD
variants vhangup() is almost a no-op. Even when it works as documented,
it doesn't affect /dev/tty. So much for tty security.

SunOS 4.1 rlogind, as well as the telnetd and rlogind distributed with
that ``critical'' security patch, uses a pseudo-tty security test
roughly equivalent to that included in my pty 3.0 package several months
earlier. Unfortunately that's not enough. Even if Sun did manage to find
a reliable tty security test, what would they do about programs like
``script''? Or screen, or emacs, or anything else which wants a
pseudo-tty? Currently many programs are expected to be setuid so that
they can chmod their ttys and write utmp entries. Not only does the tty
system become totally unmanageable, but crackers get a dozen more entry
points to a typical system than they would have otherwise. Do you really
think that emacs and screen and xterm are safe programs to have running
setuid root?

Process groups are a problem because, once again, they introduce a new
method of process communication. In BSD 4.2, process groups were
completely unprotected, and crackers could abuse them easily. BSD 4.3
tightened up somewhat by adding relations between process groups and
controlling ttys. I've proposed a somewhat simpler set of process group
manipulation calls---three primitives, instead of BSD's six, with no
need for cttys---but process groups remain an alternate method of
process communication, making security analysis and programming much
more difficult than they would be otherwise. At least process groups add
some functionality to the system, so they're almost excusable. (To
implement the job control user interface without pgrps would require a
multiplexing shell and zero-length pipes or some similar mechanism.)

POSIX sessions stand in stark contrast to process groups in that they
add absolutely nothing to the system, from either the user's point of
view or the programmer's point of view. They simply get in the way.
POSIX defined all sorts of ad-hoc rules relating sessions to pgrps,
cttys, signals, and even basic I/O. These rules have neither rhyme nor
reason. POSIX sessions are, of course, yet another form of interaction
between processes, and as we've seen in this thread they cause serious
problems under SunOS---problems which can easily be seen as security
holes. I've caught three bugs (so far) in BSD 4.4 which can be blamed
directly on POSIX sessions: for instance, any user can log any other
user out without taking advantage of any form of process communication
other than sessions. This one's been fixed, and I imagine that Sun's
fixing its telnetd problem, but do you really think that this is the end
of the POSIX fiasco?

---Dan

 
 
 

telnet to a certain machine logs me out

Post by Alain Brossard EPFL-SIC/S » Thu, 13 Feb 1992 20:10:17


(This thread should really be in comp.sys.sun.admin)


|>
|> >I modified the pty allocation code in telnetd likewise (and in GNU
|> >emacs, and in script, etc...), and the problem vanished. Perhaps Sun
|> >has a patch for this problem (I doubt it). Maybe 4.1.2 fixes it.
|>
|> 4.1.2 does *not* fix it.  I have a new patch (100125-05), which I
|> haven't tried yet.  Note the -05; Sun has been batting this one around
|> for a while.  100125-05 is a new in.telnetd, which just missed 4.1.2.

Whether or not it fixes whatever (I couldn't find the thread locally),
the in.telnetd of 4.1.2 is more recent than the one in 100125-05:

4.1.2:

root%sasun1[117]$ ls -l in.telnetd
-rwxr-xr-x  1 root        24576 Oct 23 18:33 in.telnetd

100125-05:

sasun1[196]$ ls -l in.telnetd
-rwxr-xr-x  1 brossard    32768 Jul  9  1991 in.telnetd

   Note how the one in the -05 patch is older, both those dates come
directly from the appropriate patch file.
--

Alain Brossard, Ecole Polytechnique Federale de Lausanne,
        SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211

 
 
 

telnet to a certain machine logs me out

Post by Rob McMah » Sat, 15 Feb 1992 02:06:20



Buchholtz) writes:

>>I modified the pty allocation code in telnetd likewise (and in GNU emacs,
>>and in script, etc...), and the problem vanished. Perhaps Sun has a patch
>>for this problem (I doubt it). Maybe 4.1.2 fixes it.

>4.1.2 does *not* fix it.  I have a new patch (100125-05), which I haven't
>tried yet.  Note the -05; Sun has been batting this one around for a while.
>100125-05 is a new in.telnetd, which just missed 4.1.2.

I've been into this in some detail, and have been talking to a (very patient)
HotLine guy at Sun about it for some time.  It's quite clear to me that
patching every client that uses pty's is just ridiculous, and a fix that just
replaces in.telnetd is not really a fix at all.

There is a real patch, called 100414-01 for 4.1.1 and 4.1, but it clashes with
another important patch, 100188-01 (which stops random people from grabbing
the console).  Since 100188 is rolled into 4.1.2, this also means that there
is currently no patch available for 4.1.2.  I have a test version of an -02
release of 100188 which is supposed to fix both problems for 4.1.2, but,
although it works, I wouldn't like to make this available yet, until it's
approved.  Hassle your support people.  A 4.1.1 merge of 100188 and 100414 is
also supposed to be in the works (I have a number of Sun-3 systems which also
need the fix, but which are obviously not able to run 4.1.2).

You can get the 100414-01 and 100188-01 patches from

        ftp.warwick.ac.uk:pub.sun-fixes/4.1.1/{100414-01,100188-01}.tar.Z

but you might want to wait for the -02 version of 100188 to be approved and
made available.

Here's the README from 100414-01
==============================================================================
Patch-ID# 100414-01
Keywords: application, previous, get, security, session, telnet, pseudo-tty, pty
Synopsis: SunOS4.1;4.1.1: programs using pty get output from previous application
Date: 25/Oct/91

SunOS release: 4.1.1, 4.1

Unbundled Product:

Unbundled Release:

Topic: In ptcopen(), setup a check to see if slave side is in use.

BugId's fixed with this patch: 1070495

Architectures for which this patch is available: sun3, sun3x, sun4, sun4c

Patches which may conflict with this patch: 100187, 100188

Obsoleted by:

Files included with this patch: tty_pty.o

Problem Description:
This problem affects every application using psudo-tty.

It can be reproduced in the following way :
- from a cmdtool run
        # netstat 3 &
- kill the cmdtool
- start a new cmdtool and you can get the output
 from netstat.
==============================================================================

and from 100188-01

==============================================================================
Patch-ID#  100188-01
Keywords: TIOCCONS
Synopsis: SunOS 4.1.1: TIOCCONS redirection is a security violation.
Date: 15/Dec/90

SunOS release: 4.1.1

Unbundled Product:

Unbundled Release:

Topic:

BugId's fixed with this patch: 1008324

Architectures for which this patch is available: sun3 sun3x sun4 sun4c

Patches which may conflict with this patch:

Obsoleted by: Next major release of SunOS

Problem Description: TIOCCONS can be used to re-direct console output/input
                     away from "console"
==============================================================================

There's no README for 100188-02, it's too early.

Cheers,

Rob
--
UUCP:   ...!mcsun!uknet!warwick!cudcv   PHONE:  +44 203 523037

Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

 
 
 

telnet to a certain machine logs me out

Post by Charles H. Buchhol » Sat, 15 Feb 1992 04:20:15


brossard: (This thread should really be in comp.sys.sun.admin)

You're very right; I just cross-posted and redirected followups.  For
those just tuning in, we're discussing the problems which occur when a
process (telnet, rlogin, xterm, emacs, or whatever) tries to use a pty
that is already being used by another process.
---------------------------------------------------------------------------

tadr: I modified the pty allocation code in telnetd likewise (and in GNU
tadr: emacs, and in script, etc...), and the problem vanished. Perhaps Sun
tadr: has a patch for this problem (I doubt it). Maybe 4.1.2 fixes it.


chip: 4.1.2 does *not* fix it.  I have a new patch (100125-05), which I
chip: haven't tried yet.  Note the -05; Sun has been batting this one around
chip: for a while.  100125-05 is a new in.telnetd, which just missed 4.1.2.

brossard: the in.telnetd of 4.1.2 is more recent than the one in 100125-05:
brossard:
brossard: 4.1.2:

brossard: root%sasun1[117]$ ls -l in.telnetd
brossard: -rwxr-xr-x  1 root        24576 Oct 23 18:33 in.telnetd
brossard:
brossard: 100125-05:

brossard:
brossard: sasun1[196]$ ls -l in.telnetd
brossard: -rwxr-xr-x  1 brossard    32768 Jul  9  1991 in.telnetd


chip: who confirmed that regardless of the version numbers and dates, the
chip: -04 patch made it into 4.1.2, but the -05 patch didn't.  The -04
chip: telnetd got a new version and date when 4.1.2 was built.
chip:
chip: The 100125-05 telnetd seems to help, but of course it doesn't do
chip: anything about the similar problems with X11R4 xterm, openwindow
chip: xterm, GNU-emacs, screen, etc, etc, etc.  It has been mentioned that
chip: this problem is inherent in the Posix handling of ptys; I am not
chip: qualified to comment on that.


              School of Engineering and Applied Science
                      University of Pennsylvania