The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1990)
DOCUMENT: Rutgers 'Security List' for September 1990 (9 messages, 5571 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1990/09.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
From:      bruno%sdcc10@ucsd.edu (Bruce W. Mohler)  8-SEP-1990  5:44:35
To:        misc-security@sdcc6.ucsd.edu
We have an ethernetted environment of many UNIX boxes all
running a fairly old application.  The users of the application
do *not* rlogin to different machines; they just log onto the box
over a LAN, then they log off when they're done (only the people 
who provide support use rlogin).  The only use of client server 
programs is for locally developed systems to fix problems in the 
application.

The application was implemented with many group ids (which are
going away -> towards individual user ids).  As we're proceeding
in this direction, we're thinking about a password server running
as a client/server over the ethernet (implemented so that the
users are unaware that there's a password server or anything
magical).

I've read most of the Kerberos documents and while I'm amazed, it
seems like overkill for our environment (none of the users even
know what a program is let alone a client/server).

Does anything exist like a password server?  Something simpler
than Kerberos doing login authentication?

Suggestions welcome!  Pointers to articles or research welcome!
Thoughts and inspirations equally welcome!

Thanks, in advance.

Bruce
-----------[000001][next][prev][last][first]----------------------------------------------------
From:      jkp@cs.HUT.FI (Jyrki Kuoppala)  10-SEP-1990  8:46:40
To:        misc-security@uunet.uu.net
I have put some security articles I have for anonymous ftp in
nic.funet.fi [128.214.6.100] directory pub/doc/security.

//Jyrki
-----------[000002][next][prev][last][first]----------------------------------------------------
From:      consp04@bingsuns.cc.binghamton.edu (Dan Boyd)  10-SEP-1990  9:18:28
To:        misc-security@rutgers.edu
	In 'The Cuckoo's Egg', the hacker was using an account
belonging to someone who wasn't around any more.  Password expiration
doesn't really protect against this.

Daniel F. Boyd                       | Teriyaki walking sticks!
Student Consultant, SUNY-Binghamton  | Hit those fish over the head with 
consp04@bingvaxu.cc.binghamton.edu   | these, and if they get away,
				     | you just eat the sticks!
-----------[000003][next][prev][last][first]----------------------------------------------------
From:      hollombe@ttidca.tti.com (The Polymath)  10-SEP-1990  9:43:03
To:        misc-security@decwrl.dec.com
Use the hacksaw.  If it's a cheap Master lock you should be able to cut
through it in under five minutes.

-- 
The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: hollombe@ttidca.tti.com)
Head Robot Wrangler at Citicorp(+)TTI             Illegitimis non
3100 Ocean Park Blvd.   (213) 450-9111, x2483       Carborundum
Santa Monica, CA  90405 {csun | philabs | psivax}!ttidca!hollombe
-----------[000004][next][prev][last][first]----------------------------------------------------
From:      smb@ulysses.att.com  11-SEP-1990  5:48:48
To:        hardiman@csd4.csd.uwm.edu
Cc:        security@rutgers.edu
Ftp to athena-dist.mit.edu, and look in the pub/kerberos directory.
There's also a mailing list (kerberos-request@athena.mit.edu will
add you), which is gatewayed to a newsgroup.

For a slight dissenting perspective, you may want to retrieve a draft
of a paper by myself and Mike Merritt on the limitations of Kerberos.
It's dist/kerblimit.ps on inet.att.com.

		--Steve Bellovin
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Aug 90 12:24:57 PDT
From:      black@darkside.com (Black Death)   11-SEP-1990  6:05:10, black@darkside.com (Black Death)
To:        misc-security@ucbvax.berkeley.edu, misc-security@ucbvax.berkeley.edu
        Yes, but if the users choose good passwords, there won't be much 
chance of anyone getting in at all. One good method is using a variety of 
upper & lower case (ie pAsSwOrD) on UNIXs that will alow you to do that. 
Another system which would make it nearly impossible to hack (beleive me, I 
know) would be to take two words, combine them together and add a two-digit 
number to the end (ie RUNWALK23)..If password security is not enough for 
your system you may wish to invest in a filter 
device, which will dramaticly reduce the numbe of people who even make it to 
the "password:" prompt. It is important, however, that even when you get one 
of these, you must still use good passwords.  That should drasticly reduce 
the amount of unwanted visitors on your system.
-----------[000006][next][prev][last][first]----------------------------------------------------
From:      spaf@cs.purdue.edu (Gene Spafford)  11-SEP-1990  6:29:29
To:        misc-security@gatech.edu
I just received a copy of the book "Rogue Programs: Viruses, Worms,
and Trojan Horses," edited by Lance J. Hoffman.  The book is published
by Van Nostrand Reinhold, copyright 1990, ISBN 0-442-00454-0.  The
publisher's suggested list price is $32.95, in softcover.

This book is a collection of 27 articles and book excerpts about
"vandalware" on computer systems.  Contributors include Len Adleman,
Anne Branscomb, David Chess, Fred Cohen, George Davida, David
Ferbrache, Michael Gemignani, Harold Joseph Highland, me (!), Ken
Thompson, Steve White, and many others.  The table of contents lists
the following parts: Overview of Rogue Programs, Social and Legal
Issues and Effects, Rogue Programs and Personal Computers, Rogue
Programs and Networks, and Emerging Theory of Computer Viruses.

Perhaps I'm somewhat biased because I'm the author or co-author of 3
of the 27 contributions.  However, I believe this is the most
comprehensive collection on the topic currently available.  It
contains case studies, theoretical analyses, legal opinions, and
step-by-step technical information.  The book is valuable as both a
technical reference and as a textbook around which a course can be
organized.  I'm sure it is going to become one of the 2 or 3 standard
references in the field (the forthcoming book from ACM Press edited by
Peter Denning will probably be the other).

If you are interested in some of the issues involving viruses, worms
and vandalware, you really should get a copy of this book and check it
out.

-- 
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu	uucp:	...!{decwrl,gatech,ucbvax}!purdue!spaf
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 90 07:55:00 GMT
From:      V111N5B7@ubvms.BITNET (__Robby__)
To:        misc.security
Subject:   Burglar Alarms -- Beware of cheap parts

A little ways back I posed the question to the net as to what may cause
spuratic, seemingrandom triggers of an armed alarm on a still day, the alarm
being compmosed of two simple loops with only two contact switches and the
rest vibration sensors.  The responses were quite helpful in pinpointing the
problem; it was suggested that resistance was accumulating in the circuit
perhaps due to a staple through a wire or a bad switcleading to the eventual
threshhold exceedance.

Well, after two years with this problem, I narrowed the problem down to a
defect inherant in the part!  I don't have the catelog no. handy, but a phone
conversation with Tandy's engineers in Texas confirmed that the silver mixture
used in the contacts of the switch oxidize extremely rapidly.  His solution
was to either file the contacts every 3-5 months with emery cloth, spray them
with a conducting oil (only a temporary solution) or wait till they come up
with a replacement part for it (and we all know how long THAT can take)
*sigh*.

Isn't it comforting to know that defective parts that people rely on for
safety and protection remain on the shelves going unnoticed by the consumer
AND the dealers? (detect sarcasm)

Does anyone know of any good manufactures of vibration-type switches??  Any
help would be greatly appreciated.

-----------[000008][next][prev][last][first]----------------------------------------------------
From:      hobbit@pyrite.rutgers.edu (*Hobbit*)  2-OCT-1990  1:58:36
To:        security@pyrite.rutgers.edu
I have been very busy moving my entire life and stuff to Boston, and have had
utterly *no* time to deal with the list for the last few weeks.  I now intend
to shovel out all the back messages, but I wanted to ping the readership at
large first and get a few opinions about the relative worth of keeping this
list going.

I have often toyed with the idea of just taking it down completely.  I seem
to be perpetually too busy to get things out on what you'd call a timely
basis.  More importantly, most of the recent submissions seem to either be
about things that have been discussed in the past, or are questions about
very specific and narrow fields of interest that often serve to only confuse
the readers who don't know anything about it.  Many questions could be
answered by digging around through the archives, which are all still online
from the lists's inception.  Over the years a fairly useful body of knowledge
has been captured there, and it's been my suspicion that we've just sort of
reached our horizon of getting new knowledge into there.  I could be quite
wrong about this since new security topics are always coming out, but I
see definite repeating patterns here.

The other thing is that there is now this alt.security newsgroup.  This is a
completely unmoderated instant-turnaround group, which sort of flies in the
face of this list's original philosophy.  Any clown could send in "gee, I
found this really cute hole under Buglix 5.2 and here's how to reproduce it",
raising a certain flame war as well as possible liability issues or at least
the wrath of local system folks.  Moderation, it was hoped way back when, was
one way to avoid this sort of thing.  I even took pains to run the list in
such a way that someone couldn't just "VRFY security-outbound" or some such
and obtain the distribution list for themselves.  Of course anyone could send
this sort of message to just about any group, so the question here is: Just
what does a moderated list do for people?  Should it remain moderated?  I have
noticed that the signal-to-noise ratio on alt.security is at the typically
low Usenet-like level.  I do reject a good proportion of mangled, irrelevant,
stupid, or redundant messages, but being such a filter is a rather tedious
job even with a multitude of tools at one's disposal.

So I solicit opinions from the readership.  Should the security list become an
unmoderated reflector?  Should it just shrivel under the onslaught of
alt.security and just vanish, leaving only its archives?  Should the task [and
I don't use the word lightly] of moderation pass on to someone else with more
time to do it?  I do wish I had the time to do as thorough a job as, say, PGN
with RISKS; but with new locations and new jobs and scads of loose ends to wrap
up such is not to be the case.

Suggestions and such will be accepted at my address, security, security-
request, etc; it all points to my mailbox anyway.

_H*

END OF DOCUMENT