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 May 1990 (44 messages, 25400 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1990/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Tue,  1 May 90 11:20:43 -0500 (CDT)
From:      "Anthony A. Datri" <datri@convex.com>
To:        security@rutgers.edu, simsong@athena.mit.edu
Subject:   Re: problems with shar files
Such a program was written and much debated over more than a year ago. 
You can probably find it in comp.sources.unix.

As for uuencode -- uuencode isn't really the best choice, since passage
over (for example) evil IBM mainframe/BITnet links has a way of
corrupting the files.

All too many of the uuencoded files I receive have screwy permissions
specified for the destination files, so I cd to /tmp before unpacking
them by default.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 May 90 08:30:21 GMT
From:      Bart Massey <bart@videovax.tv.tek.com>
To:        misc-security@tektronix.tek.com
Subject:   Re: problems with shar files
These discussions (which seem to recur interminably on Usenet)
almost always end in the same way, namely with the realization that
if you are about to compile and run some random giant source (or worse
yet run some random binary) on your box, horsies in the *shar file*
are the *least* of your worries...

My general strategy is to never unshar, compile, or run anything until
I've waited a few days for someone else on the net to get bit.  Selfish,
but probably effective. :-)  It certainly saved me from the April Fool's
shar of a couple years ago.

					Bart Massey
					
					Tektronix, Inc.
					TV Systems Engineering
					M.S. 58-639
					P.O. Box 500
					Beaverton, OR 97077
					(503) 627-5320

					..tektronix!videovax.tv.tek.com!bart

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Tue,  1 May 90 14:18:09 EDT
From:      wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 erebus.att.com!wcs)
To:        misc-security@att.att.com
Subject:   Re: problems with shar files
]Well, you get the idea.  Richard Stallman suggested that one way
]around this problem would be for newsgroups to send out uuencoded tar

Even that's not enough.  I once worked on a bid where the customer
(a Large Government Agency who should know better) wanted to make
sure your proposed system could read tapes made on their old small
UNIX system.  So they sent bidders the demo tape - a cpio tape
containing one file "/etc/inittab".  I figured out the tape format,
which was of course undocumented, easily enough, so I knew what was
on it, but if you just blindly read the tape, either it fails
because you're not root, or it overwrites a critical system file.
Real bright.

Basically, the alternatives are either to examine the archive before
use, or to use an archive format and reader that NEVER do bad
things.  Yeah, right.  If you're worried, examine the archive first;
there are programs like "sharks" which do an ok job of predicting
what a shell will do, but it's tough to be bulletproof.
-- 
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Fax 949-4876.  Sometimes found at Somerset 201-271-4712

# When *everything* is outlawed, only outlaws will have everything!

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 May 90 18:18:09 GMT
From:      wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 erebus.att.com!wcs)
To:        misc.security
Subject:   Re: problems with shar files

]Well, you get the idea.  Richard Stallman suggested that one way
]around this problem would be for newsgroups to send out uuencoded tar

Even that's not enough.  I once worked on a bid where the customer
(a Large Government Agency who should know better) wanted to make
sure your proposed system could read tapes made on their old small
UNIX system.  So they sent bidders the demo tape - a cpio tape
containing one file "/etc/inittab".  I figured out the tape format,
which was of course undocumented, easily enough, so I knew what was
on it, but if you just blindly read the tape, either it fails
because you're not root, or it overwrites a critical system file.
Real bright.

Basically, the alternatives are either to examine the archive before
use, or to use an archive format and reader that NEVER do bad
things.  Yeah, right.  If you're worried, examine the archive first;
there are programs like "sharks" which do an ok job of predicting
what a shell will do, but it's tough to be bulletproof.
-- 
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Fax 949-4876.  Sometimes found at Somerset 201-271-4712

# When *everything* is outlawed, only outlaws will have everything!

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 May 90 18:40:46 GMT
From:      shawn@eddie.mit.edu (Shawn F. Mckay)
To:        misc-security@uunet.uu.net
Subject:   Re: Call for Security Hacks
> I knows dozens of methods for breaking into computers.  But how do I
> know I can safely send them to you?

This is a good question; However, if you have something good to
offer the world, and wish to be sure, you can send mail to me and
I will provide for an acceptable verification; (Probably someone
you can call or a department to call, and permit you to look up the
number....).

The release date for this security package looks like end of summer
now, and will NOT be posted, insted it will be made available to any
VERIFIED site that would like a copy.

					Thanks,
					  -- Shawn

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      2 May 90 02:22:29 GMT
From:      davy@itstd.sri.com
To:        misc.security
Subject:   White paper available: "Improving the Security of Your UNIX System"

A new white paper from SRI International's Information and Telecommunication
Sciences and Technology Division is now available.

The paper, "Improving the Security of Your UNIX System," describes measures
that you as a system administrator can take to make your UNIX system(s) more
secure.  Oriented primarily at SunOS 4.x, most of the information covered
applies equally well to any Berkeley UNIX system with or without NFS and/or
Yellow Pages (NIS).  Some of the information can also be applied to System
V, although this is not a primary focus of the paper.

An abbreviated Table of Contents:

	1. INTRODUCTION
		The Internet Worm, the Wily Hacker, other break-ins
	2. IMPROVING SECURITY
	   2.1 Account Security
	   	Passwords, expiration dates, guest accounts, group accounts,
		Yellow Pages
	   2.2 Network Security
		Trusted hosts, secure terminals, NFS, FTP, TFTP, mail,
		finger, modems and terminal servers, firewalls
	   2.3 File System Security
		Setuid shell scripts, sticky bit on directories, setgid
		bit on directories, umask values, encrypting files,
		devices
	3. MONITORING SECURITY
	   3.1 Account Security
	   	lastlog, utmp, wtmp, acct
	   3.2 Network Security
	   	syslog, showmount
	   3.3 File System Security
	   	find, checklists, backups
	   3.4 Know Your System
	   	ps, who, w, ls
	4. SOFTWARE FOR IMPROVING SECURITY
	   4.1 Obtaining Fixes and New Versions
	  	Sun fixes on UUNET, Berkeley fixes, SIMTEL-20 and UUNET,
		vendors
	   4.2 The npasswd Command
	   4.3 The COPS Package
	   4.4 Sun C2 Security Features
	   4.5 Kerberos
	5. KEEPING ABREAST OF THE BUGS
	   5.1 CERT
	   5.2 DDN Management Bulletins
	   5.3 Security-related mailing lists
	6. SUGGESTED READING
	7. CONCLUSIONS
	REFERENCES
	APPENDIX A - SECURITY CHECKLIST

In order to format the paper, the "troff" text formatter and the "-ms" macro
package (available with any Sun or Berkeley UNIX system) are required.  You
*do not* need a PostScript printer, unless you want to print the cover page
with the SRI logo on it.

The paper is available via anonymous FTP from the host SPAM.ITSTD.SRI.COM
(128.18.4.3) as the file "pub/security-doc.tar.Z".  Be sure to remember to
set "image" mode on the transfer.  Sorry, UUCP access is not available - if
you don't have Internet access, find a friend who does.

Enjoy.

Dave Curry

SRI International
Information and Telecommunications
Sciences and Technology Division
333 Ravenswood Avenue
Menlo Park, CA 94025
(415) 859-2508

davy@itstd.sri.com

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 May 90 06:23:55 GMT
From:      gwyn@SMOKE.BRL.MIL (Doug Gwyn)
To:        misc.security
Subject:   Re: problems with shar files

>I started wondering if this common practice of unsharing
>files without detailed, line-by-line inspection, isn't asking for a
>disaster.

Yes, it is, for reasons such as you outlined.

ANY operation of untrustworthy software can do similar nasty
things.  In the case of programmable software such as the shell,
this has to include the data files (such as shar archives) that are
used as programs.

Without unduly crippling the user environment, about all you can do
is to educate users about this sort of pitfall, and make sure that
you vigorously prosecute (or persecute, your choice) anyone you can
catch causing such mischief.  The system administrator should also
be made the main point of contact for installing imported software,
and should understand how to check it for security problems before
installing it.  The users should be made to expect the system
administrator to perform such tasks.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 May 90 06:23:55 GMT
From:      Doug Gwyn <gwyn@smoke.brl.mil>
To:        misc-security@rutgers.edu
Subject:   Re: problems with shar files
>I started wondering if this common practice of unsharing
>files without detailed, line-by-line inspection, isn't asking for a
>disaster.

Yes, it is, for reasons such as you outlined.

ANY operation of untrustworthy software can do similar nasty
things.  In the case of programmable software such as the shell,
this has to include the data files (such as shar archives) that are
used as programs.

Without unduly crippling the user environment, about all you can do
is to educate users about this sort of pitfall, and make sure that
you vigorously prosecute (or persecute, your choice) anyone you can
catch causing such mischief.  The system administrator should also
be made the main point of contact for installing imported software,
and should understand how to check it for security problems before
installing it.  The users should be made to expect the system
administrator to perform such tasks.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 May 90 00:08 PDT
From:      "Ned Freed, Postmaster" <NED@hmcvax.claremont.edu>
To:        security@pyrite.rutgers.edu
Subject:   Re: Locks/Security in large institutions (e.g. Universities)
I was one (of many, I suspect) who destroyed the security at my high school.

The system was a Corbin removable core setup with grand masters and
great grand masters. It also had a novel setup we called construction
pinning. A very small pin was placed in one of the pin columns and keys
were issued that always caused this pin to fall below the line between the
core and the cylinder. However, once a key was used that would turn the
lock with this pin ABOVE the line, it would fall into a little dimple
in the cylinder. The result was that all keys issued originally would no
longer work. Our assumption was that this feature was intended for use
during building construction, since every one of these we encountered
in a completed building had the pin stuck in the dimple. This also
implied that there would be TWO control keys, one for before and one
for after. The control key would not upset the setting of the construction
pinning since the control alignment level was different enough (and
besides, the lock did not turn on the level with the dimple when the
control key was used).

We happened across a couple of locks that were DISCARDED during some
construction. Incredibly stupid. This was all we needed to produce
all the possible control keys. Blanks were no problem either. The
blank is registered, but we found that sheet metal worked just fine!
(No bending was needed, and the resulting key was a lot more durable than
the regular soft brass). We made enough control keys to finally find the
right one.

We never did much with the keys except fix about 10 locks that were
busted because of incompetent installation. This took most of the
spare parts from the locks we scavenged, but I still have the discarded
cores kicking around somewhere, I think.

Incidentally, the codes were not stamped anywhere on the cores. The keys,
however, had a code number on them that was easily transformed into the
pinning code for that key. This did not apply to grand masters and
great grand masters, which had a funky number on them, nor control
keys, which were simply stamped CONTROL (a friendly locksmith showed me
his keychain one time, also not a smart thing to do...).

There were no other security features to prevent picking in these
locks, but there was one thing to prevent picking at the control level --
that row of holes in the bottom of the control shell that you find in
some Best locks was not present in these Corbin locks. They really
were impossible to pick at the control level. But given all the other
problems with the system, I was not impressed then, and I'm not impressed
now.

				Ned Freed

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 May 90 19:40:07 GMT
From:      phil@zorch.sf-bay.org (Phil Gustafson)
To:        misc.security
Subject:   Security Horror Story

I was briefly associated with a local computer manufacturer in late 1985.
Of the hundred or so employees, perhaps half used the local systems regularly
and virtually all of them knew the root passwords.  And the network was such
that "root" on any system could gain root priveliges on any other system on
the net.

I visited the company last summer as a consultant to a third party.  The
third party software was installed somewhere on the network, and my host
did not know where.  He wandered off to find it.  Having nothing better to
do, I found a terminal and decided to poke around myself.  I logged in as root,
using the password from nearly four years earlier.  It worked fine.

NOte that:

	The company had not done well and had had high turnover.  As far as I
	could tell, no technical people from 1985 were still with the company.
	All the former staff knew the root password.

	When I was there the host computer was one of the manufacturer's own.
	It had been replaced by a more well-known system.  The old password
	remained.

	After my visit last year, my host asked me how I managed to log on
	as root.  I told him.  He asked me what password I used.  I told him.

I assume that after that chat the password was changed.  The company is no
longer in the usenet map and may well have gone out of business.

To me, it seems reasonable to change root passwords every few months and every
time a root user leaves the company.  This is _not_ paranoid and IMHO helps
_protect_, rather than penalize, former employees.  

Readers with stale old root passwords be warned.

						phil

------------------------------------------------------------------------------
	Opinions outside attributed quotations are mine alone.
------------------------------------------------------------------------------
-- 
  |  phil@zorch.SF-Bay.ORG 		 | Phil Gustafson
  |  (ames|pyramid|vsi1)!zorch!phil 	 | UNIX/Graphics Consultant
i |					 | 1550 Martin Ave., San Jose CA 95126
  |					 | 408/286-1749

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 May 90 06:24:12 EDT
From:      amb@hudson.cs.columbia.edu (Andrew Boardman)
To:        security@pyrite.rutgers.edu
Subject:   Re: re^2: Locks/Security in large institutions (e.g. Universities)
Unlike many other places cited here, Columbia University isn't quite in
the middle of nowhere, and the security here is constantly evolving to
deal with being in a neighborhood that isn't exactly the best.  (Although
I would classify no place in New York City to be 'safe'...)  There are a
few different coring systems for different sets of buildings; the whole
mastering layout is *completely* chaotic, and the only organized layout
is in the undergraduate housing, which follows conventional mastering
schemes.  Student copying of keys is rampant, and I believe they do play
"musical locks" with the cores each year.  (A common set of cores can be
circulated around a half-dozen buildings, always with a good number in
reserve.  The students are charged a whopping $50 for a simple core swap
if they lose their keys -- it's more of a deterrent than an actual
representation of any costs.  At one point (I used to hang around the
locksmiths' work area for the residence halls) someone had to go out to a
large building which required four lock changes -- he just swapped the
cores around and redistributed keys.)  The University depends far more on
the 24-hour posting of security people everywhere than physical security,
even though there are two full-time locksmiths attached to the just the
student housing people, and another seven or so for the university at
large, who have their fun making their own cores in the style of the
better Medecos, and unique "in-house" blanks and such...  Alas, the
standard key is from a set of far-from-secure Russwin blanks.  My
question is, were these things being pushed heavily at academic
institutions at one time?  I've hung around quite a few schools, and far
too many of them were using Russwin's for my comfort...

(The undergrad housing is gradually switching to these horrible Ving
punched-card style keys -- they don't work well at all, but they're cheep
cheep cheep, and they come as sets of long plastic cards, one end of
which is the key, the other end of which you stick in the back of the
lock after lifting a fragile (and often broken) plastic hatch.  Instant
disposable lock "cores".

Andrew Boardman     no mail to amb@ai.ai.mit.edu, MIT's ITS's are going to die
amb@cs.columbia.edu  ...rutgers!columbia!amb  amb%cs.columbia.edu@cuvmb.bitnet

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 09:26:00 EDT
From:      "Pennypacker, Bruce" <90_pennypab@gar.union.edu>
To:        "security" <security@pyrite.rutgers.edu>
Subject:   Best Locks
  They use Best locks here at our campus, but I know for a fact that they 
  dont even faze anybody determined to open one.  They do charge students
  $10 if they don't return keys, but that doesn't deter much.  As a freshman
  I forgot (really forgot) to turn in my dorm room key at the end of the 
  year.  They tacked on the $10 to my overall bill, and for the rest of my
  time here (I'm now a senior) I've had a key into one of our dorms, and 
  I probably could have also gotten into my old room if I really wanted to.

  As for duplicating Best keys, all you have to do is make a round of local
  locksmiths...  Most of them don't care if the key says "Do not duplicate" or
  "Unlawful to duplicate".  There is a locksmith that is about a 2 minute
  drive from our campus which will duplicate ANY key from our campus as long
  as the person getting the duplicate will sign a statement that states that
  he/she has the permission/authority to get the key duplicated and that the
  locksmith can't be held responsible for anything that may happen as a result
  of the duplicates.  There's another locksmith about 30 minutes away that won't
  even bother with this... Just walk in, drop down the keys, and he duplicates
  them.  Face it, they just want the money.  They don't care what you're gonna
  do with the keys.

  During the past four years I've had so many Best keys pass through my hands
  that (if I really wanted to) I could have duplicated them all and had access
  to most of the areas on our campus.  Once you have access to certian areas
  you can also find master keys to other areas.  For instance, our computer
  department has keys to most of the campus since all of our buildings have 
  data ports to hook up to our mainframes.  If I could get into our computer
  center, find those keys, and duplicate them all one weekend when they
  wouldn't be missed, then I'd be set for life.

  Just a few thoughts...

  Bruce Pennypacker
  90_PENNY@UNION.BITNET
  90_PENNYPAB@GAR.UNION.EDU

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 10:24:12 GMT
From:      amb@HUDSON.CS.COLUMBIA.EDU (Andrew Boardman)
To:        misc.security
Subject:   Re: re^2: Locks/Security in large institutions (e.g. Universities)

Unlike many other places cited here, Columbia University isn't quite in
the middle of nowhere, and the security here is constantly evolving to
deal with being in a neighborhood that isn't exactly the best.  (Although
I would classify no place in New York City to be 'safe'...)  There are a
few different coring systems for different sets of buildings; the whole
mastering layout is *completely* chaotic, and the only organized layout
is in the undergraduate housing, which follows conventional mastering
schemes.  Student copying of keys is rampant, and I believe they do play
"musical locks" with the cores each year.  (A common set of cores can be
circulated around a half-dozen buildings, always with a good number in
reserve.  The students are charged a whopping $50 for a simple core swap
if they lose their keys -- it's more of a deterrent than an actual
representation of any costs.  At one point (I used to hang around the
locksmiths' work area for the residence halls) someone had to go out to a
large building which required four lock changes -- he just swapped the
cores around and redistributed keys.)  The University depends far more on
the 24-hour posting of security people everywhere than physical security,
even though there are two full-time locksmiths attached to the just the
student housing people, and another seven or so for the university at
large, who have their fun making their own cores in the style of the
better Medecos, and unique "in-house" blanks and such...  Alas, the
standard key is from a set of far-from-secure Russwin blanks.  My
question is, were these things being pushed heavily at academic
institutions at one time?  I've hung around quite a few schools, and far
too many of them were using Russwin's for my comfort...

(The undergrad housing is gradually switching to these horrible Ving
punched-card style keys -- they don't work well at all, but they're cheep
cheep cheep, and they come as sets of long plastic cards, one end of
which is the key, the other end of which you stick in the back of the
lock after lifting a fragile (and often broken) plastic hatch.  Instant
disposable lock "cores".

Andrew Boardman     no mail to amb@ai.ai.mit.edu, MIT's ITS's are going to die
amb@cs.columbia.edu  ...rutgers!columbia!amb  amb%cs.columbia.edu@cuvmb.bitnet

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 May 90 16:44:25 CST
From:      Kevin LaFata <S899229@umslvma.bitnet>
To:        security@tcsvm
Subject:   Alarm Equipment
   There is another good place to get alarm equipment. They may not have many
control panels, etc, but they specialize in door/window contacts. They also
have a good selection of glass break detectors and motion sensors. They mainly
deal to quailifed alarm installers, but I don't think you would have any
trouble ordering single qty's of things. They're called Sentrol and the phone
number is 1-800-547-2556. They are a good source for people who want to
have a do-it-yourself alarm since many local distributers will not sell to
to individuals especally if they do not have a license.

                    Kevin LaFata
  S899229@UMSLVMA

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 12:59:19 GMT
From:      Doug Gwyn <gwyn@smoke.brl.mil>
To:        misc-security@rutgers.edu
Subject:   Re: re^2: Locks/Security in large institutions (e.g. Universities)
"Do not duplicate" stamping is not very effective.  Best had a series of
key sections (J, K, L) for which blanks were simply unavailable, and the
so-called "M" blanks that passed A-G (maybe H) sections would not fit
these.  That's of course not an absolute deterrent (I had a friend who
filed a blank out of a scrap piece of stainless steel), but so far as I
could tell it did thwart *most* of the college students who specialize
in lock cracking.  (Too bad course credit wasn't available for this work.)

The funny thing about the control (core removal) key was that you could
make one upon inspection of a single core, and it was just as good as a
great-grandmaster key, so long as nobody was watching while you used it.
(Once the core is removed, the actuator can be turned by a special torque
tool or even an ordinary screwdriver.)

Better than drilling the front of the lock cylinder is milling a channel
down the top; if properly done you can extract the pins (use a 45-degree
angled pin punch to uncap a pin column), remove the core, repin it, and
restore the whole assembly to the door from which it was removed.  (You
might fill the milled channel with solder before reassembly.)  However,
eventually somebody is bound to get upset at the property damage.

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 22:44:25 GMT
From:      S899229@umslvma.BITNET (Kevin LaFata)
To:        misc.security
Subject:   Alarm Equipment


   There is another good place to get alarm equipment. They may not have many
control panels, etc, but they specialize in door/window contacts. They also
have a good selection of glass break detectors and motion sensors. They mainly
deal to quailifed alarm installers, but I don't think you would have any
trouble ordering single qty's of things. They're called Sentrol and the phone
number is 1-800-547-2556. They are a good source for people who want to
have a do-it-yourself alarm since many local distributers will not sell to
to individuals especally if they do not have a license.

                    Kevin LaFata
  S899229@UMSLVMA

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 19:58:33 GMT
From:      knight@csli.stanford.edu (Bob Knight)
To:        misc-security@decwrl.dec.com
Subject:   Off the wall...ROM security?
I know that these newsgroups are not exactly on target for this subject,
but I don't see any that are closer.  My apologies...

Is there available on the market any device to prevent copying and/or
reverse engineering of EPROMs?  If so, I would be most grateful for
any and all information I receive.

Please mail  to me directly.  I'll summarize if there's interest.

Thanks,
Bob

knight@barton.com

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 22:27:40 GMT
From:      roeber@POOH.CALTECH.EDU
To:        misc.security
Subject:   Expired passwords `change it there-and-back' problem

When I was at CERN, I knew a system manager who had a policy against such
changes.  He would read the security logs daily, and among other things 
would note password changes.  When he saw somebody change their password
two or more times in a short period of time (a few days or so), he'd assume
they were restoring their original password (unless they contacted him and
told him a good reason).  He would then expire the password, and increase 
the minimum length by two.  This policy was mentioned in the welcome banner,
and he had little trouble with this problem.  Last fall, when I ran a cluster,
I announced this policy.  Nobody said a word.  I never saw anybody pulling
this trick, and even though we have had a new manager for awhile, I still
haven't seen it.
	Cheers,
Frederick.
-------------------------< Frederick G.M. Roeber >---------------------------
roeber@caltech.edu or | 222-89 Caltech | Disclaimer: Are you kidding? If more
roeber@caltech.bitnet | Pasadena, CA   | people shared my opinions, the world
((00)1 818) 568-9516  |      91126 USA | would be a much happier place.
-----------------------------------------------------------------------------

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 May 90 22:27:40 GMT
From:      roeber@pooh.caltech.edu ()
To:        security@pyrite.rutgers.edu
Subject:   Expired passwords `change it there-and-back' problem
When I was at CERN, I knew a system manager who had a policy against such
changes.  He would read the security logs daily, and among other things 
would note password changes.  When he saw somebody change their password
two or more times in a short period of time (a few days or so), he'd assume
they were restoring their original password (unless they contacted him and
told him a good reason).  He would then expire the password, and increase 
the minimum length by two.  This policy was mentioned in the welcome banner,
and he had little trouble with this problem.  Last fall, when I ran a cluster,
I announced this policy.  Nobody said a word.  I never saw anybody pulling
this trick, and even though we have had a new manager for awhile, I still
haven't seen it.
	Cheers,
Frederick.
-------------------------< Frederick G.M. Roeber >---------------------------
roeber@caltech.edu or | 222-89 Caltech | Disclaimer: Are you kidding? If more
roeber@caltech.bitnet | Pasadena, CA   | people shared my opinions, the world
((00)1 818) 568-9516  |      91126 USA | would be a much happier place.
-----------------------------------------------------------------------------

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 May 90 10:56 +1200
From:      Simon Travaglia <CCC_SIMON@waikato.ac.nz>
To:        security@rutgers.edu
Subject:   Security and Masterkeys
I've always wondered about the safety involved in masterkeying and who
gets the masterkeys.

   We had an incidence here a while ago now, where the cleaners room
got broken into and various masterkeys were taken.  The cleaners room
was probably one of the worst "defended" places in the university, it's
an external door (to outside) was a internal-type door {you know, the
sort that's not solid but stuffed with cardboard} and all the master-
keys left there overnight.  That's not so bad, but the cleaners' door
has one of those "Lock inside handle" locks, which you could pry open
with a screwdriver!

Masterkeys should:
		- Never be leant to anyone
		- Stamped "DO NOT DUPLICATE"
		- Not be Identified with the place they masterkey
			(I.e. stamped IMK - Better to have a system
			of codes that isn't duplicated on the lock)
		- Not ever stamped {whatever}MK - a dead giveaway
		- Always be accounted for/LOCKED away

Then there's the complacency that some people treat the loss of a
MK. "Don't worry, it'll be round here somewhere" is a common response,
in which the person has no idea where the key is but is prepared to
trade knowledge for HOPE!

Let's face it; locks buy you time and if worst comes to worst, someone
will put a truck thru the side of your building or axe a hole in your
wall to get in if it's that important.  CCTV cameras (Monitored),
{one at each end of a corridor covering the other} are a bloody good
deterrent {until some masked individuals spray paint the lens} because
there's always the chance of identification.

Has anyone, as an exercise, tried to make a very highly protected area?

P.s.	We used to use those magnetic keys that have sections for
	magnets.  What a crock!  Someone showed me how "safe" they
	are with a magnetic chess set!  One of our technicians
	came in one day and was a bit exeuberent and the whole
	lock mechanism snapped off - held in by 2 screws!

-- 
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Simon P Travaglia,   || Kia Kaha E Hoa!  
University of Waikato|| PSI:0530171000004::, Intr: spt@grace.waikato.ac.nz
Private Bag, Hamilton|| Disclaimer: No-one here but me can read and write,
New Zealand          ||             and I can only write.  What did I say?
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Remember, even if you win the rat race, you're still a rat.

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Sat, 05 May 90 12:15:42 EDT
From:      Peter Jones <MAINT@uqam.bitnet>
To:        Security discussion list <security@ohstvma>
Subject:   Theft of ATM with a front-end loader
On the radio newscasts this morning, there was a report of a gang of thieves
who arrived at an ATM in a shopping plaza in a stolen truck. They unloaded
a front-end loader from the truck, crashed it through a wall, picked up
the ATM, containing some $96,000 Can, and loaded it in the truck, and then
drove off. Witnesses claim the entire procedure took about a minute!

How about some countermeasures? I've thought of a few:

1) Sturdier construction and installation

2) Camera surveillance

3) A method of staining the bills, making them worthless (this method is used
  in the briefcases of messengers carrying money).

"Let your flippers do the walking" :-)
Peter Jones                    (514)-987-3542
Internet:Peter Jones <MAINT%UQAM.bitnet@UGW.UTCS.UTORONTO.CA>  ?
Internet:Peter Jones <MAINT%UQAM.bitnet@ugw.utcs.utoronto.ca>  ?
UUCP: ...psuvax1!uqam.bitnet!maint

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 May 90 02:13:49 GMT
From:      root@zardoz.cpd.com (Operator)
To:        uunet!misc-security
Subject:   netstat problem
I would strongly urge every site on the internet to immediately chmod
the program "netstat" so that "others" cannot execute it.

chmod o-rwx /usr/ucb/netstat

[Moderator tack-on: Anyone care to expand upon this?   _H*]

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 May 90 00:54:10 PDT
From:      "diamond@tkovoa" <diamond@tkou02.enet.dec.com>
To:        misc-security@decwrl.dec.com
Subject:   Re: Internet Security
>       For example, BSD based systems will allow you to
>       pick a stupid password by repeating it three times.
 
In principle, this is a feature.  The system reminds the user that the
user is making a mistake, but the user is allowed to make her own choice
(level of security).
 
The principle matters more in other cases:  When an installation chooses
users' passwords, or makes things too difficult, then the user has to
write down the password.  This might make the problem worse instead of
better.  However, the traditional Unix "recommendation" is not overly
demanding on a person's ability to memorize.
 
>       Also, many systems enforce standards for everyone except root!
 
Yes, in this case, Unix returns to its usual philosophy.  Instead of
assuming that the user knows what she wants, the assumption is that
the user never makes a mistake.  When the user is root, the system
declines to remind the user that something might be a mistake.
(Well, at least passwd only thinks that superusers are perfect.
The rest of Unix, and C, assume that ALL users want to avoid error
checking.)
 
-- 
Norman Diamond, Nihon DEC     diamond@tkou02.enet.dec.com
This_blank_intentionally_left_underlined____________________________________

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      7 May 90 12:35:00 EDT
From:      "zmudzinski, thomas" <zmudzinskit@imo-uvax.dca.mil>
To:        "security" <security@rutgers.edu>
Subject:   Morris Sentenced - Washington Post Article
  From Page A1 of _The_Washington_Post_, Saturday, 5 May 1990 -- QUOTE:

NO JAIL TIME IMPOSED IN HACKER CASE
Creator of `Virus' Gets Probation, Fine

By John Burgess, Washington Post Staff Writer

    Robert Tappan Morris, the graduate student who created the celebrated 
computer "virus" that paralyzed thousands of research computers nationwide 
in 1988, yesterday [4 May] was sentenced to three years' probation, fined 
$10,000 and ordered to perform 400 hours of community service.  He received  
no jail time.

    Morris was the first person to be brought to trial under a 1986 federal 
law designed to shore up security for the computer systems that are playing 
an increasingly critical role in American life.  His trial and sentencing   
had been closely watched by computer specialists for signs of how the justice 
system woul treat a virus case.

    Yesterday, some of these specialists argued that jail time was necessary 
to send a strong deterrent message against tampering with computers.  Others 
said that prison time would have been an overreaction to the acts of a young 
man they felt intended no harm and was guilty mainly of youthful bad judgement.

    Morris, 25, smiled broadly after his sentencing by U.S. District Judge 
Howard Munson in Syracuse, N.Y.  Morris hugged his mother, shook hands with 
his father and left the building without commenting.

    Keith Bostic, a University of California software specialist who helped 
stop the virus's spread, welcomed the decision not to send Morris to jail.  
"He was playing with fire, but he didn't really mean to burn anybody," said 
Bostic, who was called as a witness by the prosecution during Morris's trial.

    Strong condemnation came from Rep. Wally Herger (R-Calif.), author of 
legislation that would outlaw viruses.  "I am very disappointed that the 
sentence did not include some prison time for this serious offense," Herger 
said in a statement.  "In this ground-breaking case, we must send a strong 
message that computer virus outbreaks will be punished severely."

    Computer viruses are programs--sets of instructions that tell a computer 
what to do--that replicate themselves and spread from computer to computer 
over telephone lines or exchanged data discs [sic].  They can cause harm by 
deliberately destroying information or taking up so much room in an infected 
computer's memory that normal functions are slowed or shut down.

    In November 1988, a virus raced across a national network of interlinked 
research computers known as the Internet, paralyzing or slowing down almost 
6,000 machines in companies, government laboratories and universities but 
destroying no information.  The case attracted international publicity and 
led to calls for new laws to close what were perceived as loopholes.

    The virus was quickly traced to Morris, at the time a Cornell University 
graduate student.  He became a symbol of the computer "hacker" community, 
in which software enthusiasts delight in penetrating computer security 
arrangements.  Further interest was created by the fact that Morris's father, 
Robert Morris, was a senior computer scientist at the top-secret National 
Security Agency.

    Morris's trail began in January and became a test case for whether the 
1986 law, which does not mention viruses specifically, would be adequate to 
obtain a conviction.

    During the trial, Morris testified that the virus was an experiment that 
had run out of control due to a programming error.  He was convicted and 
faced up to five years in prison and a $250,000 fine.

    Jude Franklin, who oversees computer security for Planning Research 
Corp., a McLean-based computer services company, said the prosecution and 
conviction of Morris would do the job of deterrence.  The $10,000 fine was 
"severe" for a graduate student, Franklin said.

    "Clearly he's learned a lesson," Franklin said yesterday.  "And much more 
importantly, the community of bright young graduate students and really 
bright hackers . . . have learned that this is not something they can do."

    But elsewhere, the sentence was called lenient.  Justice Department 
spokesman Doug Tillett said the department was "a little disappointed."  
U.S. Attorney Frederick J. Scullin, who oversaw the prosecution, noted in a 
statement that future offenses of this type would be prosecuted "vigorously."

    Lance Hoffman, a George Washington University professor who specializes 
in computer security, declined comment on whether Morris deserved jail.  But 
he said the sentence's lack of jail time will means [sic] the message sent to 
hackers will not be strong.

----------------------------------------------------------------- END QUOTE

Personal Note:  There will be many flamers on this, and I think that before 
the hotter-headed among us start burning old UNIX workstations on the 
Morris's lawn, we should remember that we are part of a nation of laws.  
I do not agree with Judge Munson's sentence; I think it is little more than 
a slap on the wrist (does anyone REALLY believe that RTM Jr. won't get a 
bigger advance from his publisher than the $10K fine?); *B*U*T* Mr. Morris 
has been convicted and sentenced AND THAT'S THE END OF IT.

Thank you.

Tom Zmudzinski,
Former DDN Network Security Officer

"Posterity, you will never know how much it cost...           
 ...to preserve your freedom!  I hope you make good use of it"
    	 			        -- John Adams  

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      7 May 90 20:43:01 GMT
From:      karkania@aecom.yu.edu (George Karkanias)
To:        misc-security@uunet.uu.net
Subject:   summary of inexpensive antitheft devices for autos
	Well, as I promised, once the responses stopped pouring in I
would post a brief summary.  My initial post requested info on 
"inexpensive antitheft deterrents".  Many responses were redundant
and so I've combined them.

			SUMMARY

1)	Removable steering wheel: Cost under $100.  Info on manufacturer not
	provided.

2)	Installing your own ignition kill switch:  Find wire, which runs down
	steering column.  This wire is normally dead except when you crank
	the car.  This wire can be broken (low voltage side), and you can
	splice in enough wire to run to a hidden toggle switch or unlabeled
	switch.  When you leave the car the toggle switch can be set to the
	off position, the circuit will not be complete and the car won't
	crank.  Parts needed are inexpensive: electrical wire and a switch.
	J.C. Whitney's sell several other alarms for those in the NYC area.

3)	Fuel cutoff:  A similar concept to #2 but the idea is to cutoff the 
	fuel supply via a hidden toggle switch.

4) 	Steering wheel locks:  These devices attach to the steering wheel 
	and prevent the steering wheel from turning.  Many people have
	pointed out that these wheel locks are not effective against
	an skilled thief.  They point out that although the wheel lock
	itself is difficult to cut, the steering wheel isn't.  Also it 
	was stated that freon or frozen Co2 can be sprayed on the device 
	and then easily cracked.  Locks are also available which lock the
	brake pedal to the steering column.

5)	Manually disconecting components:  You can remove the spark plug
	wire, or the wire from the coil to the distributor, disabling the 
	car.  This may be useful if the car is
	left parked on the street for long periods of time and if a hood
	lock is used in conjunction.

6)	Lojack system:  a more sophisticated approach.  This is a radio
	based system with which police can keep track of the location
	of your car. OK this one might not be so inexpensive :-)

7)	Fake alarms:  This deterrent is simply the installation of blinking 
	lights etc. designed to mimic more expensive alarm systems to 
	discourage a thief.

		OTHER GENERAL SAFETY TIPS

1)	Park in a well lighted area.
2)	Keep valuables out of sight.
3)	Keep license and registration in your wallet or purse.  These items 
	help thieves to sell your car when stolen or to impersonate you if
	questioned by police.

	Well, I hope this helps others as it did me.  Thanks Again!! to all
who provided this information.

-- 
George Karkanias: Dept. of Neuro. AECOM
                  Bronx, NY 10461 

and remember  "Never play leapfrog with a unicorn."

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 May 90 18:34:37 EDT
From:      "Larry Margolis" <MARGOLI@ibm.com>
To:        security@pyrite.rutgers.edu
Subject:   Opening a safe by manipulation
All Group II safe locks, by definition, can be manipulated.  Group I locks,
which are mostly sold to the government, are not susceptible to manipulation.
(And Group I R are also proof against radiological attack - i.e., they have
plastic wheels so they can't be X-rayed.)

I believe the reason for this is that the manufacturers want the locksmith to
be able to open the (group II commercial) safe if the combination is lost, or
if someone messes up trying to change the combination.  Manipulating it open
is cheaper than drilling it.  The government, on the other hand, doesn't care
if someone gets in to the safe *provided they leave evidence they have done
so*.  If the safe is drilled, blown, etc., then they know that someone has the
secrets that were stored therein, and can take appropriate measures.  What they
don't want is someone to be able to manipulate the safe open, copy the secret
material, and then close it up leaving no evidence of tampering.

Larry Margolis, MARGOLI@YKTVMV (bitnet), MARGOLI@IBM.COM (csnet)

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      10 May 90 19:57:45 GMT
From:      blount@MEDIA-LAB.MEDIA.MIT.EDU (Alan Blount)
To:        misc.security
Subject:   a new scam

Here's one a little on the James Bond side: Someone takes a 9"
monitor, keypad, PC, magstripe reader, and some minor metal hardware and
builds a bogus Baybank or other ATM machine.  Then he places it in a
convincing location (replace a disused doorway in a shoping district)
around Christmas for a few hours.  It accepts cards, scans the back,
and after accepting the password says "Sorry, unable to process your
transaction at this time."  All the culprit must then do is write the
stripe to blank magcards and use them and the password on a real
machine.

Placement of the bogus machine is the most difficult part.  But I
figure the total investment is only around $1500 or so, which can be
made back on 3 cards...

Alan Blount
blount@amt.mit.edu

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 07:00:02 GMT
From:      wine@CS.UCLA.EDU (David Wine)
To:        misc.security
Subject:   book recommendation

What book on computer security issues would you recommend for
a master's course?  Send directly to me and I will summarize
to the net.

--David Wine		wine@cs.ucla.edu

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 22:00:47 GMT
From:      stanonik@nprdc.navy.mil (Ron Stanonik)
To:        misc-security@ucsd.edu
Subject:   hosts.equiv/4.3bsd/sunos4.0.3
We noticed that if hosts.equiv contains a "host user" pair, then it allows
that user from that host to rlogin/rsh/rcp as anyone (except root) on the
local machine.  For example, if the hosts.equiv on kickme contains

	arf ron

then ron from arf can rlogin to kickme as anyone (eg, rlogin kickme -l bin).

We ran into this while trying to allow rcp for users who don't have
directories (hence no ~/.rhost), while trying to avoid making machines
completely hosts.equiv.

Ron Stanonik
stanonik@nprdc.navy.mil
ucsd!nprdc!stanonik

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      12 May 90 17:43:47 GMT
From:      schwartz@boulder.colorado.edu (Mike Schwartz)
To:        misc-security@ncar.ucar.edu
Subject:   Re: problems with shar files
You could do a "chroot" to somewhere safe and then read the tape.
 - Mike Schwartz
   Dept. of Computer Science
   U. Colorado - Boulder

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      15 May 90 08:07:58 GMT
From:      annala@neuro.usc.edu (A J Annala)
To:        misc-security@ucbvax.berkeley.edu
Subject:   Re: Morris Sentenced - Washington Post Article
If the term had been invented, I would most likely have been considered a
major network hacker from the mid 1960's through the early 1970's.  There
were no specific laws on the books to preclude this activity.  Indeed, my
peers engaged in frequent arguments about moral, ethical, and even legal
standards that should be applied to such activities.  However, it was not
until the mid 1970's that laws were passed forbidding unauthorized access
to computer systems and networks.  When these laws were enacted we stayed
away from the kinds of attacks forbidden by the new rules.  No one wanted
to take a criminal conviction of any kind without much better reason than
mere curiosity or the challenge of seeing whether a new idea would work.

I subsequently worked as a"contract employee" providing technical support
for foreign operations by a three letter agency, as a data communications
security duty officer for another federal organization, and as manager of
academic computing for a major state university.  I am now teach graduate
courses in computer science, engineering and business administration with
several courses focusing on security threats and countermeasures relevant
to large information processing organizations.  

There is no doubt that computer crime (including network hacking and many
other forms of intrusion) now cost businesses and the governmenet a large
amount of money in the form of extra work to secure systems & intentional
theft of information, unauthorized modification, and destruction of data.
However, the prosecution failed to prove RTM intentionally harmed any of
the systems his worm penetrated.  Instead, the evidence tended to support
his claim that the harmfull consequences were largely unintentional.  If
he had set out to steal information, modify or destroy large amounts of
data there is no doubt his sentence would have been substantially greater.
Indeed, when we catch someone with such malicious intent we will need to
clearly distinguish their crime from RTM's case and throw the book at the
purpetrators.  However, in light the nature of this case, I believe the
sentence is entirely appropriate.  The frequent calls for a five year jail
term and $250,000 fine amount to the "final solution" with RTM as victim.
Such a "final solution" would not be justice for RTM's unintended crime.

Please keep in mind that RTM has suffered an arrest, brief jail time, very
intensive interrogations, serious criminal charges, conviction of a federal
felony, three years probation, 400 hours community service, and a $10,000
fine.  He has not walked away scott free.  In addition, he had to pay for
a very costly defense against the combined juggernaut of numerous federal
agencies and many other organizations screaming for a show trial and the
heaviest possible sentence.  RTM is a marked man.  His felony conviction
will follow him forever.  I seriously doubt whether RTM or anyone else who
is aware of the circumstances of this case would willingly submit to the
same penalties without a better reason than intellectual curiosity.

As far as more dangerous computer criminals ... let's catch one and go for
the throat.  The Arizona Attorney General's Office keeps testifying about
purpetrators stealing millions of dollars using computers and networks as
their working tools.  Catch just one ... hang them high ... and we may be
able to bring an end to such things.  But sending RTM to jail to be gang
raped or otherwise destroyed is not the answer to serious computer crime.

Any email replies to annala@neuro.usc.edu are quite welcome.

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 May 90 08:09:39 EDT
From:      simsong@next.cambridge.ma.us (Simson L. Garfinkel)
To:        LCO114@uriacc.bitnet
Cc:        security@pyrite.rutgers.edu
Subject:   Factoring Large Numbers
>   Storage is cheap.  Start your favorite CRAY Multiplying prime numbers,
>   store the results, indexed.  Come back in a year or so with the list
>   of astronomical numbers you want factored, and look them up...

You mean, come back after the end of the Universe, don't you?  Do you
know how big 2^800 really is?  My calculator won't go higher than
2^332 (which is 8.749 x 10^99)

Using 2^332...

If you could find and multiply a million prime numbers every second
(and you can't ... the real number is more like a single prime number
every six months once you get large enough), then you would need
8.74 x 10 ^ 93 seconds, or 2.77 ^ 10 x 86 years.

If the expected time-to-live of the Universe is on the order of a
billion years, you would have to keep your computer running through
approximately 2.77 x 10 ^ 75 cycles of the Universe in order to factor
that many numbers.

By the way, storage isn't that cheap.  Especially for more digits than
there are atoms in the Universe.

[Moderator tack-on: Thanx to many other folks for doing the math on this one;
I got snowed with replies!  Point most decidedly taken by now; enough on
this subject, please... _H*]

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      16 May 90 12:09:39 GMT
From:      simsong@next.cambridge.ma.us (Simson L. Garfinkel)
To:        misc.security
Subject:   Factoring Large Numbers

>   Storage is cheap.  Start your favorite CRAY Multiplying prime numbers,
>   store the results, indexed.  Come back in a year or so with the list
>   of astronomical numbers you want factored, and look them up...

You mean, come back after the end of the Universe, don't you?  Do you
know how big 2^800 really is?  My calculator won't go higher than
2^332 (which is 8.749 x 10^99)

Using 2^332...

If you could find and multiply a million prime numbers every second
(and you can't ... the real number is more like a single prime number
every six months once you get large enough), then you would need
8.74 x 10 ^ 93 seconds, or 2.77 ^ 10 x 86 years.

If the expected time-to-live of the Universe is on the order of a
billion years, you would have to keep your computer running through
approximately 2.77 x 10 ^ 75 cycles of the Universe in order to factor
that many numbers.

By the way, storage isn't that cheap.  Especially for more digits than
there are atoms in the Universe.

[Moderator tack-on: Thanx to many other folks for doing the math on this one;
I got snowed with replies!  Point most decidedly taken by now; enough on
this subject, please... _H*]

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 May 90 15:07 MET
From:      "Kees de Groot, Information Systems Security" <DEGROOT@rcl.wau.nl>
To:        security@pyrite.rutgers.edu
Subject:   Prevention of trojans
prevention of viruses in the DECUS Program Library

        These days many people are hesitating to use public domain
        software. This might become a problem for the DECUS
        Program Library. The DECUS Program Library is a big
        repository of very useful software for DEC's machines
        like Rainbow, Professional, PDP11 and VAX. The PL is run
        by volunteers selling software, submitted by
        DECUS-members, to DECUS-members.

        A lot of things can be done to prevent Trojan-problems:

        - demand and verify the name and/or organization of the
          submitter of the software
        - always demand the sources and full documentation
        - test the software
        - implement a file-CRC-checksum procedure to be sure the
          received software is the same as originally submitted

        A lot of questions and problems remain however:

        - testing the software costs a lot of time.
          More than a volunteer can offer perhaps.
        - how do you check source code for Trojans?
          Ever tried to check more than 20 pages of BLISS,
          assembler, C or PASCAL?
        - is there a file-CRC-checksum procedure that can be used
          for a variety of machines and operating systems?
        - are there other solutions for this problem?
        - anyone having ideas, thoughts, experience, pointers?

Tel. +31-8370-  .KeesdeGroot   (DEGROOT@RCL.WAU.NL)   o\/o  THERE AINT NO
     (8)3557/   Computer Systems Security              []   SUCH THING AS
        4030    Inform. & Datacomm.  Dreijenplein 2   .==.  A FREE LUNCH!
                6703 HB  Wageningen, the Netherlands
                X25:    PSI%(+204)18802031937::DEGROOT
disclaimer:     I always speak for myself
- if you go too far to the east, you find yourself in the west ..  -

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 04:59:26 GMT
From:      mcgp1!jgo@thalatta.com (John Opalko, N7KBT)
To:        misc-security@ms.washington.edu
Subject:   RS-232 encryption boxes??
I need to secure some communications lines between several terminals and a
UNIX machine.  The security doesn't have to be super-duper-tip-top-secret-
destroy-before-reading, but it does have to make it difficult for
eavesdroppers.

Here's a diagram of what the end product will (supposedly) look like:

+----------+     +-----+     +-------+
| Terminal |-----| BOX |-----| Modem |----\
+----------+     +-----+     +-------+     \
                                            \
+----------+     +-----+     +-------+       ----------+-------+
| Terminal |-----| BOX |-----| Modem |-----------------| Modem |-----+
+----------+     +-----+     +-------+       ----------+-------+     |
                                            /     ^                  |
+----------+     +-----+     +-------+     /      |                  |
| Terminal |-----| BOX |-----| Modem |----/       +--POTS lines      |
+----------+     +-----+     +-------+                               |
                                                                     |
                                                                     |
                                                                     |
                                                                     |
                                     +----------+               +--------+
                                     | Computer |    +-----+    | Packet |
                                     |    of    |----| BOX |----| Switch |
                                     | Interest |    +-----+    +--------+
                                     +----------+                    |
                                                                     |
                                                                     |
                                                                     |
                                                              +-----------+
                                                              |   Other   |
                                                              | Computers |
                                                              +-----------+

The boxes must be bidirectional (of course) and must run a reasonably
secure encryption scheme, such as DES.  The key must be readily changeable
by non-computer types, but *only from the DTE side*.  The originator of the
data call (at one of the terminals) must be able to connect in plaintext mode
to tell the packet switch s/he wants to connect to the Computer of Interest,
then switch to encrypted mode once the connection is established (really, with
the box at the other end) without dropping the connection.

The "packet switch" in the above diagram may be more than one physical
switch, linked by leased lines.

The box and associated connections between the Packet Switch and the Computer
of Interest may be many separate serial lines, each with its own box.

The idea is to give several people around the country a local number to dial
and to have the unencrypted portion of the data path be as physically short
and as easy to secure as possible.

Operations will probably be conducted at 1200 or 2400 baud, although 9600
is a possibility.

Is there such an animal as the "BOX" in the diagram?  How about a few pointers
to some vendors?

				Thanks,

				John Opalko

				jgo@mcgp1.uucp
				uunet!nwnexus!thebes!mcgp1!jgo

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      21 May 90 01:10:11 GMT
From:      annala@neuro.usc.edu (A J Annala)
To:        misc-security@ucbvax.berkeley.edu
Subject:   Cryptographic Algorithms
Where can one obtain authoritative information about the government's
interest in regulating the design, development, and dissemination of
cryptographic methods for protecting information stored on hard disks
or transmitted via common carriers (snail mail, email, ftp, and other
public transmission facilities)?  We are developing a few products to
provide cryptographic protection for confidential communications.  It
would be nice to know what limitations may be imposed on any domestic
or foreign sale of these products.  It would also be good to know who
to negotiate with for exceptions to the military munitions list.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 01:53:25 GMT
From:      strick@osc.com (HAR56)
To:        misc-security@uunet.uu.net
Subject:   Re: Best Locks
We noticed in Techwood Residence Hall at Georgia Tech that ratio of
the number of possible BEST keys to the number of doors was rather tight.

With maybe 120 rooms, most keys seem to be in the range HAR1 to
~HAR250.  It wouldn't take everyone losing their key but once or so
before these numbers could repeat.   Also out of seven notches, we
tried to guess how many notches changed and how many tumbler levels
there were.  I forget what we figured, but it seems it was bigger than
the 250 number.

Is it common practice on campi to have two locks the same, assuming
the residents will never notice?  Occasionally a group of people would
all go down a hall trying locks, but we never found a double.

p.s. are there any other HAR56's out there?

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      28 May 90 05:49:31 GMT
From:      netcom!onymouse@claris.com (John Debert)
To:        misc-security@ames.arc.nasa.gov
Subject:   Re: National Security Agency
You cannot, as a plain old, lowly American citizen, get anything from the NSA.
All requests are declined.

jd

-- 
J. DeBert			"You know your customer is a programmer
onymouse@netcom.UUCP		 when you ask 'cash, check or charge?'
 ...!apple!netcom!onymouse	 and he replies, 'yes.'"
CI$: 75530,347 | GEnie: onymouse
P.O.Box 51067 Pacific Grove, CA 93950

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 May 90 11:59:20 EDT
From:      simsong@next.cambridge.ma.us (Simson L. Garfinkel)
To:        security@pyrite.rutgers.edu
Subject:   Radionics 6112
Does anybody know anything about the radionics 6112 serial protocol?

Here's the problem.  I've got my house wired with IR devices, all tied
to a radionics 6112 panel.  There are keypads throughout the house
that communicate with the panel via a "serial bus."  Every device on
the bus has a "data in" and "data out," as well as the traditional +/- power.

The keypads, also on the bus, have little lights that turn on and off
whenever one of the zones get activated.  They also have buttons that
you can push.

I've been told that DATA runs at 300 baud.  I've looked at the data in
/ data out with a terminal, but get gibberish on data out and nothing
(literally no signal) on data in.  I called up radionics and they said
that the procol is proprietary (bastards!).  So I'm looking to see if
anybody on the net knows what is going on and (I hope) has the protocol.

The data stream is constant, although there are obviously packets
(pauses between blocks of character transmission).  There appear to be
two packet sizes: about 16 characters and about 32 characters.  The
next step, I guess, would be to build a high-precision RS232 analyizer
(I could do this in software) to find the breaks between the packets,
and look for characteristic start/stop signals and stuff like that.

Of course, I can always use a parallel interface and just read the
lights directly.  But that would be a real kludge.

Any help would be greatly appreciated.

			Simson L. Garfinkel
			simsong@next.cambridge.ma.us

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 May 90 13:33:51 CET
From:      "SGT Richard A. Welch - System Administrator" <asqexlim08@oberursel-emh1.army.mil>
To:        security@pyrite.rutgers.edu
Subject:   Expired passwords `change it there-and-back' problem
Frederick,
   As the System Administrator of a medium sized system I have found the best
way to adminisister the password problem is to assign passwords and remove the
passwd program (as far as anyone other than root knows).

				Rick

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jun 90 03:40:39 PLT
From:      "Craig A. Summerhill" <SUMMERHI@wsuvm1.bitnet>
To:        SECURITY@OHSTVMA
Subject:   IBM security
I am curious about something, and I was hoping the readers of SECURITY-L
might be able to provide me with some answers.

For the past two-three years I have been actively reading everything I
can get my hands on regarding computing security, and in the process
have developed a somewhat useful personal bibliographic database to
accompany my interests.  I work iin library systems, an quite honestly
computing security is an area which hasn't been convered very thouroughly
in the professional literature of the library world - thus what began
as more of a hobby for me has become more lucrative as publishing
opportunities arise for me.

At any rate - my question is this.  I have encountered many references
to security breaches on UNIX machines, and a few related to VMS machines.
The UNIX problems are understandable given the open systems philosophy of
the operating system.  What I don't understand is that I have rarely
encountered references to security breachs on IBM machines running VM or
MVS.  Why is this?

I have seen (and narrowly avoided) the "Christmas Tree" virus which
spread from the IBM INFONET to the VM/CMS community several years ago.
But, I am more interested in references to "trapdoors" and "superuser"
account priviledges that may exist.  Is the reason that I have never
seen references because they don't exist, or is it because IBM
systems analysts/programmers have been more careful in removing such
items from the systems before they go into production?

As a final note: one reference I do have to VM/370 and MVS (OS-360)
is in Charles Pfleeger's book *Security in Computing* which I purchased
as a result of some earlier discussions on this list.  However, it
doesn't go into much detail on either system.

Cheers,

Craig A. Summerhill                            THE *OTHER* WASHINGTON
Assistant Systems Librarian                 ____________________________

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 19:49:38 GMT
From:      gwyn@SMOKE.BRL.MIL (Doug Gwyn)
To:        misc.security
Subject:   Re: Security and Masterkeys

> Has anyone, as an exercise, tried to make a very highly protected area?

Of course they have, and not as an exercise either.
(Hint: Try breaking into an ICBM silo sometime.)

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 19:49:38 GMT
From:      Doug Gwyn <gwyn@smoke.brl.mil>
To:        misc-security@rutgers.edu
Subject:   Re: Security and Masterkeys
> Has anyone, as an exercise, tried to make a very highly protected area?

Of course they have, and not as an exercise either.
(Hint: Try breaking into an ICBM silo sometime.)

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 20:12:01 GMT
From:      len@CSD4.CSD.UWM.EDU (Leonard P Levine)
To:        misc.security
Subject:   Re: Security and Masterkeys

Sorry about this but anyone who has access to a masterkeyed door and a key
to fit it (just that one door) and has some time and a screwdriver can 
generate the masterkey.

It is not easy.  Take the lock apart, remove the spring cover, remove the
springs and pins, measure them, and put it all together again.  In every
case I am aware of the master key is the lowest key of all.  In any
event, you now can make a much reduced set of trial keys which may be tested
on nearby doors.

Metal keys mainly serve to keep the wind and small children out of enclosed
spaces.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                       e-mail len@cs.uwm.edu |
| Professor, Computer Science             Office (414) 229-5170 |
| University of Wisconsin-Milwaukee       Home   (414) 962-4719 |
| Milwaukee, WI 53201 U.S.A.              FAX    (414) 229-6958 |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

END OF DOCUMENT