response 82 of 187:

May 15 16:43 UTC 1997

Hm... maybe this would correlate with my other problem with my shell -- Even
tho' I've changed my .login to specify that my kill key is ^X, it still thinks
that it's ^U, and it also thinks that ^X is my reprint key.....  It's a very
confoozeledf shell..

response 84 of 187:

May 16 03:19 UTC 1997

I had the problem arianna describes once a few months ago, I think.  I also
use tcsh.

response 86 of 187:

May 16 20:22 UTC 1997

  My guess is that your shell (or comsat, or biff, or whatever it is that's
  reporting your new mail..) is merely checking the modification date on
  the mail spool file to see if it's been changed and deducing new mail from
  that.  Since pine modifies that file and writes it when it exits, maybe
  that's what's happening?

  (Although that'd be a stupid way to check for new mail..  The "right"
  way is to check the "Status:" headers on the messages to see if they've
  been read or not..)

response 88 of 187:

May 17 12:15 UTC 1997

User ariel0 wrote me to ask a aboutlosing her connection to grex:

as i get booted it gets locked up then suddenly it says connection closed by
foreign host non socket to socket operation occured

Anyone know what a non socket to socket operation is?

response 90 of 187:

May 17 18:00 UTC 1997

It would require root to change the login program.  So, Grex is as secure
against that as it is against root breakin.  If someone had root, they could
just change anyone's password anyway, so changing login is not the most
destructive thing they could do.  (However, it tcsh is seg faulting, then it's
unlikely that it's a login snooper.)

response 92 of 187:

May 18 14:20 UTC 1997

Maybe I didn't make it clear, maybe I'm way out of date.  The scheme I'm
thinking of starts with some wanna-be cracker named, say Adolf.  Adolf
writes (or downloads, or whatever) a little program that clears the
terminal screen, then writes to it the same strings that the real login
program would ("Welcome to Grex .... grex.cyberspace.org login:").  Some
other user named, say Victim, come along to use the terminal.  Victim
naturally assumes that he's seeing the login screen, enters his user name
and password, and Adolf's program stores both for future use.  Adolf's
program typically would try to die in an unsuspicious way at that point
(complain of wrong password & hope Victim assumes that it was his own 
typing error, fake a shell crash, whatever) and let the real login program
come up on the terminal.  Victim then logs in normally, and probably 
suspects nothing.  

With dial-in lines instead of physical access terminals, Adolf's program
has a tougher time of it - it has to make it through the security bottleneck
surrounding hanging up the modem and waiting for an incoming call.  But
opportunity also increases greatly - modem problems and line noise are
good, unsuspicious ways to die, and there's a much better chance that the
Victim dialing in will be root.

Adolf does not need root access to launch this type of attack on a UNIX 
system that isn't carefully designed to prevent this type of attack.  Adolf
may have no ambition higher than cracking Grex (bad enough from our point of
view!).  I agree that tcsh crashing does not represent this type of attack -
it merely brought it to mind.

response 94 of 187:

May 18 19:41 UTC 1997

eep!

response 98 of 187:

May 20 09:41 UTC 1997

How is it possible that I'm the only one logged in right now?
Wow.

response 100 of 187:

May 20 12:19 UTC 1997

Well, it's a symptom of one. Grex is off the net right now,
apparently due to problems at our ISP.

response 102 of 187:

May 20 23:25 UTC 1997

There was a big problem at IC net last night and this morning.  (We're
connected there at work too, so I know it was IC net)

response 104 of 187:

May 26 03:46 UTC 1997

Now Grex's internet link is hosed. Ping returns zero percent of packets, and
telnet does not respond.