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 (1989)
DOCUMENT: Rutgers 'Security List' for March 1989 (96 messages, 47430 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1989/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
From:      "Tarjei T. Jensen" <jensen%hsr.uninett@NORUNIX.BITNET>  2-MAR-1989  8:49:52
To:        <security@pyrite.rutgers.edu>
Somebody did something like this at our place. I don't know what they did, but
here is my suggestion of how I would do it: I would write a program that would
write protect all directories. I know that I could use something like Xtree to
do this, but I think that a program will give me more flexibility. I could for
example make it leave some directories writeable (scratch files). I would also
think of putting the unprotected files in their own partition (drive) on the
hard-disk. E.g. dirve C protected and drive D unprotected and in addition
perhaps make D small. I would also write a program that would unprotect a drive
(for maintenance). These programs would probably make a nice little student
project (or assignment). Lastly I would get a program that would reformat the
drive without destroying the data. I've heard that one should do a low level
format on a hard drive once every 6 to 12 months. I hope this sounds sensible.
-----------[000001][next][prev][last][first]----------------------------------------------------
From:      "Kenneth R. van Wyk" <LUKEN@ibm1.cc.lehigh.edu>  2-MAR-1989  8:58:23
To:        Security List <security@pyrite.rutgers.edu>
     There are a number of products that are designed to do the sort of
     thing that you're looking for.  I've tried Pyramid's PC/DACS (Data
     Access Control System), and it works pretty well if you install all
     of the options (hard disk boot protection AND disk encryption).
     You can set up individual users, with each one having access to
     whatever directories and files that you choose.  With the encryption
     installed, it seems rather thorough; without it, it's child's play
     to get around.  Of course, the encryption adds a bit of overhead to
     disk activities, but it's pretty reasonable.  Pyramid Development
     Corp. can be reached at (203)-524-9832.

     I have no connection with Pyramid other than being a satisfied
     customer.

     Ken van Wyk

Kenneth R. van Wyk                   Calvin: Mom, I'm going to grow a LONG
User Services Senior Consultant         beard like the guys in ZZ Top!
Lehigh University Computing Center   Mom: That's great Calvin, do it!
Internet: <luken@Spot.CC.Lehigh.EDU> Calvin: Wow, I thought she'd put up more
BITNET:   <LUKEN@LEHIIBM1>              of a fuss than that!
-----------[000002][next][prev][last][first]----------------------------------------------------
From:      GREENY <MISS026@ECNCDC.BITNET>  2-MAR-1989 20:57:51
To:        <security@pyrite.rutgers.edu>
> We are about to install a lab with a number of hard drives that will support
> training and general student use.  When students have access, we would like
> to make those programs and files...to be "locked" in some way.

What kind of machine are we talking about here?  Mac, IBM, etc...

On the Mac, it's relatively easy to do -- just set the FILE PROTECT bit in
the files that you don't want duplicated or moved (although it will let you
TRASH them I think...).  A utility such as MacSnoop, or FEdit will usually
do the job (I know RESEDIT wont let ya....)

As for a PC, well, you could set the HIDDEN bit on them to true so they
dont show up in the directory, and then have a batch file call em...This
ought to work (but seeing as how I use Macs, and rarely get on PC's...it
might not...)  Although I have had hidden directories, with the files
showing and had batch files like that....

Hope this helps...
Bye for now but not for long
Greeny

BITNET: MISS026@ECNCDC
Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU
-----------[000003][next][prev][last][first]----------------------------------------------------
From:      "Craig Finseth" <fin@uf.msc.umn.edu>  3-MAR-1989 19:25:03
To:        security@pyrite.rutgers.edu
Cc:        jimkirk@outlaw.uwyo.edu
"Out of band" signalling is great, assuming that you have an out of
band path.  If you're one of the enlightened (:-) Emacs users,
"obscure" sequences that "no one will ever type" are ordinary command
sequences.

Another important question is "where is the trusted path TO?"  In the
olden days when all terminals were hardwired to serial ports, you
could follow a wire and know where it went.  In the current trend
towards Ethernet terminal servers, my wire goes to that box.  A
trusted path could only be guaranteed to that box, not to the host (at
least until we improve the network protocols).

Unfortunately, the current situation leads to the operating assumption
that you don't have a trusted path.  "Don't worry, be suspicious," is
thus the motto of the day.

Craig A. Finseth			fin@msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	(612) 624-3375
-----------[000004][next][prev][last][first]----------------------------------------------------
From:      eleazar!matthews@dartvax.dartmouth.edu (Jim Matthews)  3-MAR-1989 19:45:00
To:        misc-security@rutgers.edu
>A real-life example in early November involved a so-called computer virus (a
>self-replicating program spread over computer networks and other media as a
>prank or act of vandalism), which nearly paralyzed 6,000 military and academic
>computers.

According to the MIT report on the worm this figure was derived from the
infection rate at MIT (10% of MIT hosts were hit, and there are ~60,000
Internet hosts).  Has any more credible estimate emerged?  The 6,000
figure was a guess but it is becoming a fact by virtue of repetition.

In fact, according to published reports the Computer Virus Industry
Association furnished the FBI an estimate of $100 million in damages
from the worm.  The estimate was based on the 6,000 machine estimate and
therefore postulates a cost of $16,700 per machine.  We had around
thirty machines infected here at Dartmouth but I don't think it cost us
close to $500,000.  Again, is there reason to believe these kind of
estimates?

Jim Matthews
Dartmouth Software Development
-----------[000005][next][prev][last][first]----------------------------------------------------
From:      gwyn@smoke.brl.mil (Doug Gwyn )  4-MAR-1989  0:13:03
To:        misc-security@uunet.uu.net
-[Moderator add-on: My impression was always that Cipher locks [electronic,
-five bidirectional rocker switches in a big klunky box] were different from
-Simplex locks [all mechanical, five buttons in a column or a circle].  Is
-there some name crossover or am I confused?  _H*]

You're not confused; the reason I put "Cipher" in quotes is because
they aren't really Cipher electrical locks, they're just called that
around here (actually "cipher" without capitalization).  I don't know
how this misusage started, but probably it was similar to calling all
tissues "kleenex".

Simplex locks can be manipulated.  Genuine electronic locks
cannot, although I'm sure there are other ways to defeat them.
-----------[000006][next][prev][last][first]----------------------------------------------------
From:      Will Martin __ AMXAL_RI <wmartin@st_louis_emh2.army.mil>  4-MAR-1989  0:29:44
To:        Doug Gwyn <gwyn@smoke.brl.mil>
Cc:        misc-security@uunet.uu.net
Glad to hear that steam-tunnel exploration was common at many different
universities. There must be some sort of common mindset amongst the
particular student subculture that enjoys such things. Myself, I was
a charter member of the "WUASS" - Washington University Artificial 
Spelunkers Society -- back in '63-'67 at Wash U in St. Louis. There were
about 6 of us in that group. There may have been others doing it during
the same timeframe, but we never ran into them. I'm sure people did it
in the decades before we discovered the pastime, but they left no
records that we knew of, either written or in verbal folk culture. I
wouldn't be surprised if the activity stopped after we graduated, simply
because that later period was one of campus unrest (building-burning,
etc.) which would have led to tighter security that might have cut off
the relatively easy tunnel access we enjoyed. Things might have loosened
up again in the 70's and early 80's, though. 

Regards, Will Martin
-----------[000007][next][prev][last][first]----------------------------------------------------
From:      jad@dayton.dhdsc.mn.org (John A. Deters)  5-MAR-1989  4:10:37
To:        security@rutgers.edu
There is some name confusion going on here.

We use both Cypher locks and Simplex locks in our stores.  You're right
about the (lack of) security of a Cypher lock -- I was trying to work in
a store after the last person who knew the combination had left, and
I had it open in under three minutes (using only a flashlight).

The Simplex locks can be much more secure from the viewpoint of 'breaking'
the combination, but seem to be physically weaker IMHO.  Also, with the
Simplex locks, visual surveillance of the combination can be a problem.
And they can be defeated by the oldest trick in the book -- sales
consultants who tape the locks open because they 'get in the way'. :-)

-j
-----------[000008][next][prev][last][first]----------------------------------------------------
From:      ron@ron.rutgers.edu (Ron Natalie)  5-MAR-1989  4:54:00
To:        misc-security@rutgers.edu
Hobbit is right.  Cipher locks are as he described.  Five rocker switches
run to a box usually above and inside the door.  You can program a 4 digit
sequence in them by these little patchcords inside the box.  Simplex locks
are purely mechanical which are programmed by opening them, putting in the
old combination, pushing a plunger, entering the new combination, and then
clearing it.

BRL never had any Cipher locks that I knew about, only Simplex.  The Simplex
weren't really regarded as any more secure than the plain old Seargent key
locks, key distribution was easier.  Generally they were used for things like
printout rooms and labs where they were used by a large class of people.
The secure facilities were actually deadbolted and alarmed when not attended.
Even when we used Cipher locks in the SCIF's at other jobs, they were used
only when the room was attended inside anyhow.  At night we turned on the
alarm and spun the big ol' S&G lock on the door.

What was amazing to me is the number of people who never bother to change
the Simplex locks from the 2-4, 3 combo they all get shipped with.

-Ron
-----------[000009][next][prev][last][first]----------------------------------------------------
From:      christevt@wpafb_ams1.arpa  5-MAR-1989  5:37:23
To:        "security" <security@rutgers.edu>
      Just a quick comment about Doug Gwyn's comment about what happened at 
Rice...this time regarding MIT hackers who decided to wander up the Chuck a 
piece to a little business school called Hahvahd...

      Not much happened, mainly because the group was too large...the Hahvahd 
CPs saw this group of people wandering around suspiciously (at about midnight 
or so) and immediately questioned them about why they were there, what they 
were doing, etc...

      The main point of all this is to show, once again, that not all 
universities tolerate (and NONE, of course, OFFICIALLY approve of) hacking... 
and probably especially when the hackers are from another school (who can 
forget the great Hahvahd-Yale game where MIT won?!!!)...In general, Hahvahd 
DOES NOT approve of MIT hackers...sigh...so what!

                                   ET B ME
                                     VIC
                                      !

Victor ET Christensen         		"To the last I grapple with thee,
christevt@wpafb-ams1.arpa     		From Hell's heart I stab at thee,
christevt@p6.ams.wpafb.af.mil           For Hate's sake I spit my last breath 
christevt%amsp6.decnet@wpafb-ams1.arpa     at thee!!!"   ~ Khan
-----------[000010][next][prev][last][first]----------------------------------------------------
From:      Fred Blonder <fred@brillig.umd.edu>  5-MAR-1989  9:37:08
To:        Jeff Makey <Makey@logicon.arpa>
The /dev/passwd could be made write-only. (well, write and compare
only.) If it were implemented properly in hardware it could emulate
what the Unix one-way encryption is trying to do. In fact it wouldn't
need to store the passwords in encrypted form if you could trust the
hardware.  It would just need to answer a request of the form: "Is this
uid/password combination valid?" Presumably it would have some built-in
delay and maybe an alarm it could ring if too many invalid attempts
were made in a short time.

	... would no doubt be subject to its own special class of
	attacks.

Well, the only weakness I can see here (other than a hardware attack,
in which case all bets are off anyway) is if someone emulates root and
changes someone else's password, which can be done in "standard" Unix
already. In fact, the /dev/passwd thingy would be slightly better
against even this attack, because the cracker wouldn't be able to
restore the old password to clean up after the fact.
-----
					Fred Blonder
					Fred@Mimsy.umd.edu
					uunet!mimsy!fred
-----------[000011][next][prev][last][first]----------------------------------------------------
From:      zeleznik@cs.utah.edu (Mike Zeleznik)  5-MAR-1989  9:45:39
To:        security
On the subject of reverse authentication (proving to the user that they
are talking to the system), something like the Security Dynamics SecurID
card can provide this.  A displayed number on the card changes every so
many seconds; to authenticate you simply type in the current number and
the system can authenticate you since it is time synced.  By then
requiring the system to provide the NEXT number, you can compare it with
the next one on your card, thus being assured you are talking to the
actual system.

If the Racal-Guardata product would simply allow the response from one
challenge to become another challenge (rather than forcing a random
challenge), then I think it also could provide reverse authentication.
System issues challenge, you type response.  Then your card calculates a
response from that response, which the system must also do, thus proving
who it is.  Since each challenge/response is unique, this seems immune
to replay and as safe as the original challenge/response was.  

Michael Zeleznik              Computer Science Dept.
                              University of Utah
zeleznik@cs.utah.edu          Salt Lake City, UT  84112
                              (801) 581-5617
-----------[000012][next][prev][last][first]----------------------------------------------------
From:      gmz@pbhyg.pacbell.com (Gerry Zeitlin)  5-MAR-1989 12:32:12
To:        misc-security@ames.arc.nasa.gov
According to conversations I had last fall with Bob Oechsler,
a radio journalist in the Baltimore area, two EMP barges -
Empress I and II - were actually deployed near the Patuxent
River Naval Air Station and in the Chesapeake Bay.

They may have been responsible for several calamities, including
the destruction of millions of fish, the irreparable damage to
the piers of a new bridge which has now been permanently closed,
and the explosion of a Cessna 182 as it flew over one of the
barges.  The pilot of the Cessna was killed.  His family hired
a salvage firm to dredge for the remains of the airplane, but
no debris was ever found.

When I spoke to him, Oechsler was pressing for Congressional
action on this affair.  He probably wouldn't mind my mentioning
his address, which is 136 Oakwood Rd., Edgewater, MD 21037.

Gerry Zeitlin	415-841-5910	well!gmz
-----------[000013][next][prev][last][first]----------------------------------------------------
From:      (Stephen Tihor) <TIHOR@acf6.nyu.edu>  5-MAR-1989 12:42:44
To:        <security@pyrite.rutgers.edu>
Glenn is right in that password length and lifetime can probably be traded back
and forth holding some metric of security constant.  If one of my users
complains about our relatively long password lifetimes I offer them a double
for double deal on their password:

	twice the lifetime for twice the minimum length.

Glenn is raising an interesting human interface issue when he disparages VMS's
password set of {A-Z0-9$_}*36 for not including random punctuation since the
space of possible inputs is about the right size (informationally speaking) to
collapse into an 8 byte hashed password.  [Various studies I have seen quoted
assert that english text has 2-4 bits of real information content bet letter
because of its high redundancy.  A good citation would be appreciated.]

This more realistic than the otherwise plausible idea of taking eight ASCII
characters typed in at a terminal.  Most terminals require contortions or
surgery to generate many of the possible characters and thus most passwords
will fall in a very restricted portion of the possible space.

[Still a large one but not as large as possible or even I would contend
desirable.]

Is it is better to ask for fewer characters from a wider range or more
characters that people are likely to enter?

That sounds like an interesting problem for some student in a human factors
program to consider.

The question of how many characters people can type without visual feedback and
maintain a low error rate also enters into it.  All in all I am suprised
someone hasn't done a thesis on it.
-----------[000014][next][prev][last][first]----------------------------------------------------
From:      Dr. T. Andrews <tanner@ki4pv>  6-MAR-1989 11:06:48
To:        security@pyrite.rutgers.edu
Cc:        KARYN@nssdca.gsfc.nasa.gov
) ... Congressman from California spoke about a proposed law, HR 55, 
) which would specifically make it a crime to prance about in others' 
) computer areas ...

The problem with such laws is that they are generally made by
congress.  I would not trust congress to formulate a law which
was both useful in prosecuting those cases which I would want
prosecuted, and not applicable in cases where I would not want
it to apply.

Consider that sending e-mail is dangerously close to "prancing
about in others' computer areas", as is news.  As for control
messages (eg: sendsys, newgrp, rmgrp), well, I'd sure hate to
pay a lawyer to try the case.

					Dr. T. Andrews, Systems
					CompuData, Inc.  DeLand
-----------[000015][next][prev][last][first]----------------------------------------------------
From:      "Dennis G. Rears (FSAC)" <drears@ardec.arpa>  6-MAR-1989 11:26:48
To:        KARYN@nssdca.gsfc.nasa.gov
Cc:        security@rutgers.edu
>Also this law would allow civil cases to recover damages from the
>creator of such an item...

    You don't need a specific law to collect damages.  It's already
covered under existing tort law.  Do you mean creator or
distributor?  If you mean creator, you will have to prove that he
knew or should have known that it could have been released without
his permission or knowledge.  What if he publishes it?  You get into
free speech problems.  I hope you mean the distributer.

   I agree something should be done.  DON'T COMPLETELY RELY ON LEGAL
REMEDIES.  They normally don't work.  The system is screwed up
enough as it is.

Dennis
--------------------------------------------------------------------------
			Dennis G. Rears
ARPA: drears@ac4.pica.army.mil   UUCP:  ...!uunet!ac4.pica.army.mil!drears
AT&T: 201-724-6639		 USPS:	Box 210, Wharton, NJ 07885
Work: SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806
--------------------------------------------------------------------------
-----------[000016][next][prev][last][first]----------------------------------------------------
From:      *Hobbit* <hobbit@pyrite.rutgers.edu>  7-MAR-1989 18:24:36
To:        security@pyrite.rutgers.edu
Some of you have asked about archives and such.  During the great worm
upheaval, pyrite.rutgers.edu didn't have anonymous FTP turned on.  At long
last I've installed the fixed ftpd and placed the latest archives in
/security/security.3 -- there are other files of possible interest there
too -- for internet folks to freely swipe.  If you need a different format
and can't create it on your own, let me know and I'll see what I can do for
simple fixes.

I won't talk about the continual backlog problem that makes all the messages
two weeks out of date... sigh..

_H*
-----------[000017][next][prev][last][first]----------------------------------------------------
From:      "David.J.Ferbrache" <davidf@cs.heriot_watt.ac.uk>  8-MAR-1989  7:15:34
To:        security
  This request has appeared on the bitnet virus-l mailing list, and has
  been crossposted to the appropriate comp.sys groups and to comp.risks.
  I apologise for any readers who receive duplicate copies.

       -------------------------------------------------------------
       A review of the threat posed to the security and integrity of
       microcomputer systems posed by self-replicating code segments
       -------------------------------------------------------------

I am in the process of compiling information on existing computer viruses,
with a view to the production of a technical paper reviewing the threat
to system security posed by both present computer viruses and likely
future developments.

To this end I would be very grateful for information on individual
infections, preferably detailing the symptoms observed, damage caused and
disinfection techniques applied. Naturally I am also interested in details
of the operation of the viruses, although I appreciate the reticence shown
by infected parties to disseminate any details of virus operation, on the
basis that it could lead to development of further viruses.

The technical report is part of a Doctoral research thesis in computer
security, and will be available in late May. Distribution of the technical
report will be restricted to people who have a legitimate interest
(ie systems managers, commercial concerns, research), as I expect to
review the techniques exploited by viruses in a fair degree of detail at
the BIOS/DOS interface level. The report will consider the techniques used by
virus to duplicate, the ways in which viruses gain control of the computer
system, the camouflage techniques adopted and a brief overview of the
existing computer viruses. Finally the report will consider the likely
development of the threat from viruses, and how this developing threat
can be addressed by protective software in both virtual and non-virtual
machine operating environments.

At the moment I know of the following viruses:

IBM PC MS/DOS 
1. Lehigh variant 1 and 2              2. New Zealand (stoned)
3. Vienna (Austrian, 648)              4. Blackjack (1701, 1704)
5. Italian (Ping Pong)                 6. Israeli variant 1 (Friday 13th, 1813,
                                          PLO, Jerusalem), variant 2, variant 3
                                          (April 1st), variant 4
7. Brain (Pakastani) and variants      8. Yale

Also potentially variant of the Rush Hour and VirDem viruses developed 
during the CCC's work on viruses.

APPLE MAC
1. NVir variant A and B, Hpat           2. Scores
3. INIT 29                              4. ANTI
5. Peace (MacMag)

APPLE II
1. Elk 

AMIGA
1. SCA                                  2. Byte Bandit
3. IRQ

ATARI ST
1. Boot sector                          2. Virus construction set viruses

Mainframe OS worms
1. Internet worm                        2. DECNET worm
2. BITNET Xmas chain letter

I would be grateful for any information on these, or any other viruses. 
Reports of infection may be given in confidence, in which case they will
only be used as an indication of geographical distribution of infection.

A summary of known viruses, their symptoms, geographic distribution and
known disinfection measures will be posted to the list as soon as 
sufficient information is available to prepare an interim report. 

As part of the paper I will also be reviewing the effectiveness of viral
disinfection software, and would thus be interested in details of any
software you use, its effectiveness, and availability.

Thanks for your time!

For those interested here is a summary of a few of the virus reports published
on virus-l and usenet,

   Subject, author and date                     Virus      Virus-l issue

   THE AMIGA VIRUS - Bill Koester (CATS)        SCA        LOG8805
       comp.sys.amiga, 13 November 1987

   New Year's Virus Report - George Robbins     IRQ        
       1 January 1989, comp.sys.amiga

   The Elk Cloner V2.0 - Phil Goetz             ELK        
       26 Apr 1988

   THE ATARI ST VIRUS - Chris Allen             ATARI ST   
       22 March 1988, comp.sys.atari 

   Features of Blackjack Virus, Otto Stolz      BLACKJACK  v2.24
       24 Jan 1989                              

   Comments on the "(c) Brain" Virus            BRAIN      LOG8805
       Joseph Sieczkowski, Apr 1988

   Brain and the boot sequence, Dimitri Vulis   BRAIN      v2.5
        5 Jan 1989

   The Israeli viruses, Y.Radai                 ISRAELI    LOG8805
       2 May 1988

   VIRUS WARNING: Lehigh virus version II       LEHIGH v2  v2.35
       Ken van Wyk, 3 Feb 1989

   The Ping-Pong virus, Y.Radai                 ITALIAN    v2.18
       17 Jan 1989

   Known PC Viruses in the UK and their effects MOST PC    v2.23
       Alan Solomon, 1989

   Yale Virus Info, Chris Bracy,                YALE       LOG8809a
       2 Sep 1988
        
   New Macintosh Virus, Robert Hammen           ANTI
       comp.sys.mac, 7 Feb 1989

   Hpat virus-it is a slightly modified nVIR    HPAT       
       Alexis Rosen, comp.sys.mac, 7 Jan 1989

   INIT 29: a brief description,                INIT 29    v2.18
       Joel Levin, 18 Jan 1989

   A detailed description of the INIT 29 virus  INIT 29    v2.30
       Thomas Bond, 27 Jan 1989
       
   The Scores Virus, John Norstad               SCORES     LOG8804
       info-mac digest, 23 Apr 1988

   Macintosh infection at Seale-Hayne College   TSUNAMI    LOG8808d
       Adrian Vranch, 8 July 1988
   
   DEFENCE DATA NETWORK MANAGEMENT BULLETIN,    DECNET     (see also v1.59a)
       50, 23 Dec 1988, 

   The internet worm program, an analysis       INTERNET   
       Gene Spafford, Nov 1988

I apologise for any researchers whose articles I have not cited, in what is
currently an incomplete list of references. Hopefully, this article
will be of some use in providing a general list of viruses which have
affected computer systems in the past.

Thanks for your time, and I look forward to any information you can
supply me with.

Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <davidf@cs.hw.ac.uk>
Heriot-Watt University                    Janet    <davidf@uk.ac.hw.cs>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf 
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 31-225-6465 ext 553
-----------[000018][next][prev][last][first]----------------------------------------------------
From:      ron@ron.rutgers.edu (Ron Natalie)  8-MAR-1989 14:00:31
To:        misc-security@rutgers.edu
In addition, SIMPLEX had a line in some of their sales literature
to the effect that "10,000 possible combinations makes guessing
to right one a million to one."  We should send their marketing
department to Prob 101.

-Ron
-----------[000019][next][prev][last][first]----------------------------------------------------
From:      34AEJ7D@CMUVM.BITNET  8-MAR-1989 14:13:03
To:        Security Digest <SECURITY@pyrite.rutgers.edu>
An area firm has an office area separated from the factory floor by
large windows. Recently, The management thereof decided to enhance
the security of their office area, so they installed bullet-proof
glass in those windows. The trouble is, the windows are set in a wall
made of nothing more than 3/4" plywood and 2x2's.

Thus they have given themselves the reassuring *appearance* of
increased security, without actually increasing their physical
protection one whit!
-----------[000020][next][prev][last][first]----------------------------------------------------
From:      Gary J. Rosenblum <rosenblg@cmcl2.nyu.edu>  8-MAR-1989 14:21:19
To:        security-request@pyrite.rutgers.edu
I'm not sure if this has been talked about here before, but I was starting
to add the code to sendmail (I'm running MORE/bsd from Mt. Xinu, sendmail 
version 5.61) to log the IP address and socket # on smtp connects.  This
was part one in a general beefing up of security and logging capabilities.
It dawned on me that this was done before - and indeed, many other patches
to different programs/daemons have been made by many people.  I was wondering
if it was possible for people to post these mods (as diffs, or whatever) to
the mailing list.  I know that there might be some licensing problems, etc.
This would free my time, and others, from reinventing the wheel.

Thanks.

Gary J. Rosenblum	
UNIX Systems Manager			rosenblg@nyu.edu
New York University			gary@nyu.edu

[Moderator add-on: I would have just pointed him at ucbvax for the sendmail
distribution, but there may be other things that he needs.  In any case,
please mail things to him, *NOT* the Security list...    _H*]
-----------[000021][next][prev][last][first]----------------------------------------------------
From:      nugent@anubis.uchicago.edu  8-MAR-1989 14:33:04
To:        *Hobbit* <hobbit@pyrite.rutgers.edu>
Cc:        security@pyrite.rutgers.edu
>  I believe that these are the biaxials .....  A master key for this
>  system would have two cuts right next to each other that would address
>  either offset.....

Actually one problem with the Medecos is that within a given master
key system (typically a building), all of the pin rotations are the
same for all of the changes.  If you have the lowest key to, say the
garbage room, you know the pin rotations to the grandmaster key which
opens all doors.  Because of this, the Medecos are only marginally
better than other precision locks at preventing the usual university
problem, which is a student adding a little solder to his office/dorm key
and using a file to turn it into a master key.

It probably belongs in RISKS, but I can't help commenting that when
the Biaxials first came out, the Medeco keying software had some
problems with cross-keying, with the result that one of our office
keys was also a submaster for a different series....that student had fun!

Todd
-----------[000022][next][prev][last][first]----------------------------------------------------
From:      nichols@cbnewsc.att.com (robert.k.nichols)  8-MAR-1989 14:35:16
To:        misc-security@att.att.com
Some time ago I computed 1152 (as I recall) as the number of possible
combinations -- not exactly what is implied by the "thousands of
possible combinations" claimed by the Simplex folks (recently I saw
some blurb that claimed "more than 2000" combinations).

Incidentally, if (through psychoanalysis of the user) you suspect a
"complex" combination involving 3 buttons simultaneously, your guessing
job is greatly reduced.  There are only 10 such 3-button sets, each with
only 2 other buttons to consider.

There IS a way to generate some additional combinations, although it
violates the instructions of the manufacturer to "remove your fingers
from the buttons before turning the knob," risking damage to the lock if
you're not careful when opening it.  At the end of the sequence, an
otherwise unused button can be pressed lightly, just to the point of
increased resistance, and HELD THERE as the knob is turned.  Such a
combination is distinct both from pressing the button all the way and
from not pressing the button at all.  The basic principles for
setting/changing such combinations still apply: set the combination
using the same actions you're going to use to open the lock; to change
the combination, press the present combination and, while holding the
final button(s) activate the "change" slide.

It is possible to detect such combinations through manipulation and
determine the buttons involved, but such combinations would confound
the unaware.

It never ceases to amaze me the way these very useful locks are
mis-applied (largely due to mis-information supplied by the
manufacturer).  The locks are primarily suited (at least in my mind) to
preventing casual entry to a restricted area, provided that the location
of the lock is such that anyone attempting manipulation would be
immediately observed and challenged.

	-*-		-*-		-*-

Now that I have located the papers with my old calculations, I find that
the actual number of combinations for a Simplex lock is 1082 (even worse
than the 1152 I remembered).

Just for kicks, I calculated the effect of the "trick" I mentioned
(lightly pressing some of the unused buttons and holding them while
turning the knob).  There are a total of 2163 combinations if you allow
this.  Perhaps this is what the manufacturer had in mind when claiming
"greater than 2000" combinations, but the operating instructions
expressly forbid doing this.

What puzzles me is why the lock wasn't made with 6 buttons instead of 5.
The number of combinations then rises to over a million (without
"tricks") and security against manipulation is also improved, at least
for combinations that use all the buttons.

[Moderator add-on: The above-mentioned "trick" is Simplex's "high-security-
mode", which in theory they only point out to their high-muckymuck military
customers.  Years ago at a locksmith show I had one of the Simplex reps set
"some random combo" on one of their demos to see if I could open it; he used
one of these and I couldn't get it open at the time, although I rolled out of
bed with the answer the next morning...    _H*]
-----------[000023][next][prev][last][first]----------------------------------------------------
From:      bobd@nisca.ircc.ohio_state.edu (Bob Debula)  8-MAR-1989 20:52:31
To:        misc-security@cis.ohio-state.edu
Does anyone know of a public domain or inexpensive encrytion/decryption 
package written using the NBS standard for IBM's MVS or VM operating
systems?  Please e-mail me directly.  Thanks for your help.

-- 
-------------------------------------------------------------------------------
Bob DeBula                    | Internet:   debula-r@osu-20.ircc.ohio-state.edu
The Ohio State University     |
                              | Disclaimer: These are my views, not the U's
-----------[000024][next][prev][last][first]----------------------------------------------------
From:      jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick)  8-MAR-1989 20:57:15
To:        security@pyrite.rutgers.edu
It has often been said that DES *could* be broken by brute-force using
lots of Cray-2 time and so on, and that the NSA caused the DES' key to
be just short enough that they could break it but nobody else could.
It appears now that such networks of workstations, fiddling in their
"spare time" might also be able to pull off the same trick.  Having not
studied the DES in great detail yet, how easy is it to increase the key
to 64 bits or more?  Do the key scheduling tables need lots of work to
derive?  I heard once that the research behind parts of the algorithm
were still classified.

RSA keeps sounding better and better, if it could only be made reasonably
quick.  T. Okamoto proposed a much faster method that unfortunately results
in ciphertext much larger than the plaintext (3:1);  has this method been
discredited yet?
-----------[000025][next][prev][last][first]----------------------------------------------------
From:      jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick)  8-MAR-1989 21:38:57
To:        security@pyrite.rutgers.edu
I suppose the following possibilities exist regarding lost keys --

  1.  Permanently lost.  In a field, down a rain gutter, dropped in
      curing cement, accidentally thrown out with the trash.  Obviously
      no concern about how they're marked.
  2.  Lost, then found by an honest person who returns them.
  3.  Lost, found by an honest person who decides calling is too much
      bother, or that mailing them to the address is too much bother.
      Finder throws them away.
  4.  Lost, found by a dishonest person who would like to burgle you
      but is put off by the lack of a usable address.
  5.  Lost, found by a dishonest person who is both clever and intent
      on using the key(s).

That last, and probably least likely, is what worries me.  Given just phone
number, what can be done?

  1.  Sequential search of the phone book.  Not too likely, even here in
      Laramie  :-)
  2.  Call Phone company and trick them into giving customer name and
      address, or just even name.  I've heard varying stories on this such
      as claiming you got billed for a long-distance call to that number
      and wanting to know name & address to jog your memory before really
      getting angry at the company; or posing as a telco employee who needs
      address to work on the line.  Bribes might work well too if you know
      the right people.  Telling the truth might even work ("I found this
      key with the number...").
  3.  There may be on-line ways to get this info, legitimately or otherwise.
  4.  There may be published cross-references (or maybe I'm thinking of street
      number back to name).
  5.  Call the phone number and ask for a street address so a free trip to
      Las Vegas can be awarded (YOU may not fall for this, especially if you
      KNOW you recently lost your key, but what about your 13-year old son?)
      Variations include long-lost cousins, and so on.

Clearly, using a work number as described reduces possibilities.  However,
some companies may be more lax about giving out phone information or lists
than THE phone company, and the list may be small enough to make a sequential
search feasible.

Given just a PO box number --

  1.  Walk up to box, peek in window (if windowed) to try and find a readable
      name.  Go to phone book.  Even if you have an unlisted number or use
      your PO box in the phone book, there are other publications in the
      county library that may list your name and address given name.  County
      records might also be a source.
  2.  Get the street address from the window jockey (may involve fast talk
      and/or bribe).  I had to give this when I got my box in the first place.
      I don't know what the rules are on the USPS giving out this info or what
      they want it for in the first place.

The only really safe thing to do is mark keys with somebody else's identity
such as a trusted friend or a security service bureau.  Or don't mark them,
and if you lose one, either don't worry or re-key.

Disclaimer -- I do not mean to imply that USPS or telco employees accept
bribes, or to defame them in any way.  Just considering possibilities, and
you have to admit it must happen even if only infrequently.
-----------[000026][next][prev][last][first]----------------------------------------------------
From:      Steve Lesh (ISC | howard) <lesh@brl.mil>  8-MAR-1989 22:43:41
To:        security-request@pyrite.rutgers.edu
	If anyone has or knows where I can get a copy of the security programs
in the book UNIX System Security by Patrick Wood & Stephan Kochan, I would
appreciate hearing from you.  I have the book but would like to avoid typing
all these programs.

	Thanks in advance,

			Steven Lesh
-----------[000027][next][prev][last][first]----------------------------------------------------
From:      jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick)  8-MAR-1989 22:52:53
To:        security@rutgers.edu
I have been reading up on DES and RSA encryption.  I have a question that
may or may not point out my ability to read  :-)

Let's take public-key encryption as typified by RSA.  It is a "block" cypher
in that any large message must be broken into a set of small pieces, then
each piece is separately encrypted.  For example if you have a 200-digit
key, each piece should be no larger than 200 digits.  Let's say I want to
send the message --

     DO NOT    (block 0)
     DELETE    (block 1)
     FILE 1    (block 2)

If I encrypt these and send them to the destination, but the first block
simply gets lost, the resulting message is quite different!  An active
eavesdropper will not be able to decypt them, but if he wants to be
mischevious (at the expense of possibly exposing himself) he could,
knowing my block length (after all the key is public), just drop a block.
Likewise, upon gathering several messages I've signed, he could mix and
match blocks, and end up with something that I have "provably" signed
(since each block was signed) but is gibberish or by bad luck damaging.
The latter is possible because he has access to both the ciphertext and
plain text (by decrypting using my public key) and could "cut and paste"
previously received encypted blocks.  Unless I'm reading things wrong,
RSA can only prove you signed a block, not the entire document.

Am I missing something in the algorithm, that "binds" blocks in some way
to prevent this, or is there an underlying assumption that external
means will be taken to glue the blocks in some way?  Clearly you could
include block numbers inside each block to ensure block sequence and
reception of all blocks, but this does not solve the issue of authentication
of signed messages (which could still be cut-and-pasted), and it adds more
overhead (though cheap overhead for RSA where blocks are large, this is
bad news for DES where the blocks are only 64 bits).
-----------[000028][next][prev][last][first]----------------------------------------------------
From:      smiller@cs.umn.edu (Steven M. Miller)  9-MAR-1989 11:08:26
To:        misc-security@rutgers.edu
I'm looking for a "callback" program.   i.e. a utility that will when a
user dials into a computer and logs in over a phone line he is automatically
logged out and the computer phones the user.

Does anyone know of such a program for Unix machines?  Preferably PD, but
I will pay for one too.

Thanks,

-Steve

-- 
			-Steve Miller, U of MN
-----------[000029][next][prev][last][first]----------------------------------------------------
From:      James (J.G.)Borynec <BORYNEC@bnr.ca>  9-MAR-1989 11:19:56
To:        security@rutgers.edu
Do not believe that shrink wrap is the safest way to go to avoid
viral infection.  In the last week, we have been hit by two garden
variety nVIR viri.  Both came from reputable companies.  In fact, one
came on the distribution disks for our Texas Instruments MicroExplorer.
TI phoned us about it, and sent  a virus remedy however.

I can control what software I get from other people that I know, but it
seems to me that I can't control, or even find out what precautions were
taken before the shrink wrap was put on.

Cheers ... J. Borynec
Borynec@bnr.ca.bitnet   (Bell Northern Research)
-----------[000030][next][prev][last][first]----------------------------------------------------
From:      eugene@eos.arc.nasa.gov (Eugene Miya)  9-MAR-1989 11:29:29
To:        misc-security@ames.arc.nasa.gov
>How can one defend against a virus unless they have one to look at?

Yes there are very legit reasons for writing worms.

You see the problem is that the biological analogy has overpowered your
understanding of some of these programs.  That is all they are, programs.
At one time writing compilers and operating systems had a mystic "above"
other programs.  Then it was learned mere morals could do them (well,
more mortals at least).  This is even less so with worms and viruses
which are much simpler.

These programs are destructive in some way only because of intent.
Programs of this structure can be found in system daemons, and they
will become more prevalent as we increase our use of networks,
distributed systems, remote servers, multiprocessors, and so on.

The seeds of these issues could be found on Schoch et al's CACM paper on
Worm Programs.  When they were testing on the Xerox research net,
were they stealing other people's evening cycles?  Its gets worse.
The problem is sort of like the popularity of the old TV show:
Mission Impossible.  They did neat things technically, but no one
questioned whether they were doing legal or right things.  The show went
out of fashion during Watergate, perhaps during a fit of conscience.
But now in the days of Lt. Col. Ollie North, the show reappears.
The same sort of goes with computer security.

Proposed laws are written by people who do not completely understand
these issues.  Security experts don't completely understand.  It's
interesting to note how many "experts" can't write a simple Trojan horse
shell script.

Remember they are just programs.  Their harm is subject to human
intepretation, and machines will have an even harder time discriminating.
Will virus killing programs kill daemons by mistake?

One last note: a short story.  I work on some machines which are very fast.
During the testing of one, I had a script of a workload which "got away."
The point was to run continuously by forking a new child and dying.
I tried killing it, but before I could, it always forked.  This happened
about 2 weeks before Morris.  The initial shock (panic) hit me: multi-million
dollar machine running amuck.  If Morris did accidnetly lose his program,
I think I know how he felt.  I was at least able to kill mine.

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "Mailers?! HA!", "If my mail does not reach you, please accept my apology."
  {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
  "Post follow ups.  Contribute to network noise."
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 18:57:20 GMT
From:      lesh@BRL.MIL (Steve Lesh, ISC | howard)
To:        misc.security
Subject:   security validation programs


	Thanks to all for the rather amazing quantity of responses to my
request for the security validation programs mentioned in the Kochan and Woods
book on UNIX System Security.  I NOW HAVE THE PROGRAMS.  

	I think I responded to all requests to forward these programs.  I
would be willing to act as a manual file server providing things don't get
out of hand.  Anyone knowing anything about the legal implications of posting
these programs to uunet archives might want to look into archiving the above.
There certainly seemed to be a lot of interest!

	Thanks again for the all the responses to my request.

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 06:22:37 GMT
From:      scarter@CAIP.RUTGERS.EDU (Stephen M. Carter)
To:        misc.security
Subject:   Re: appearances vs. actualities

>so they installed bullet-proof
>glass in those windows. The trouble is, the windows are set in a wall
>made of nothing more than 3/4" plywood and 2x2's.

I don't know what they make out on the factory floor, but if it has
anything that uses robot arms, milling machines, and the like, *I* would
feel a lot better on having that nice thick and hefty glass around me
than standard plate glass.   A small metal object can be thrown a fair
distance coming out of some machines.  If that object hits a large plate
glass area, watch out.

They may not be more secure, but a lot safer.

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 89 21:03:31 GMT
From:      nichols@iexist.UUCP
To:        misc.security
Subject:   Re: Simplex locks

WRT using fluorescent dye to determine used vs. unused buttons, I
suspect that a solution of ordinary laundry detergent would be the most
readily available.  The brighteners glow brilliant white under UV.

For Simplex locks, however, who needs it!?  It only takes 1 to 2 minutes
of manipulation to identify used and unused buttons, with no apparatus,
power source, or even ambient light required.  In the (uncommon) event
that all the buttons were used, there are 541 combinations to try.  If
less, the math is definitely on your side.

                   #buttons       #comb
                   5 of 5         541
                   4 of 4         75
                   3 of 3         13

					Bob Nichols
					nichols@iexist.att.com

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 89 17:02:48 GMT
From:      kdante@NOTE.NSF.GOV ("Katherine J. Dante")
To:        misc.security
Subject:   Re: Shrink wrap not safe- yet another virus story

Since computer stores have the ability to re-shrink wrap software and allow
customers to try the software out, I am not sure that shrink wrapping does
any more than assure you that the price on the wrap is the price the store
wants to charge for whatever is in the wrap.  You certainly cannot tell
whether you are getting all the disks/documentation that the manufacturer
intended.  And you have no assurance that some smart-aleck didn't plant a
virus while "checking out" the program with his own disk.

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 89 18:14:42 GMT
From:      rjg@sialis.mn.org (Robert J. Granvin)
To:        misc.security
Subject:   Security "journals"

Quite some time ago, someone posted an address and telephone number of
where to locate the "Rainbow Volumes".  Would some kind soul email me
that information?

Thanks.

-- 
       Robert J. Granvin           "Mueslix: A natural blend of oats, barley,
 National Information Services      octopi, Toyotas, cement and small furry
       rjg@sialis.mn.org            animals too slow to escape our field
{amdahl,hpda}!bungia!sialis!rjg     agents."   --'corsair'

-----------[000036][next][prev][last][first]----------------------------------------------------
From:      haynes@ucscc.ucsc.edu (Jim Haynes)  14-MAR-1989 11:54:13
To:        misc-security@ames.arc.nasa.gov
>A year or so back, users of the Cambridge University Computing Service were 
>hit by a password grabber which infested the BBC Micros used as terminals.  

Well, sure, if you're using micros as terminals, and the micros are
publicly accessible or shared, then there are all kinds of possibilities
for security cracking.

In our environment the users who use public terminals seem to like the
personalized password prompts, both for security and because they can be cute.
All we claim for them is that they will sometimes defeat the most
simple-minded password grabber programs; and that was the kind we tended to
see often in the past.  Now the method of attack has shifted to modern
high-performance password guessing programs.

haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
-----------[000037][next][prev][last][first]----------------------------------------------------
From:      "John P. McNeely" <JMCNEELY@utcvm.bitnet>  14-MAR-1989 12:14:13
To:        security@rutgers.edu
     There are two other books I know of:
      1) Dr. Fred Cohen offers a book entitled 'Computer Viruses'. It
         is based more on the theory and mathematical side of viruses. The
         book is very interesting. In order to get the book you must
         first contact Fred himself:

                Fred Cohen
                c/o Advanced Software Protection
                PO Box 90069
                Pittsburgh, PA 15224

         The book costs $20.00, which is supposed to include mailing expenses,
         with checks payable to Advanced Software Protection.

      2) Recently, Abacus publishing has released a book which is causing
         some disturbance among the computer virus "authorities";
         the book is entitled "Computer Viruses - A High-Tech Disease".
         This book gets extremely detailed whith actual code for various
         viruses on different systems. I'm still waiting on my copy but from
         what I hear it is a really good book. You can contact your local
         computer book store to get more info.

     Hope this helps.

John P. McNeely
BITNET: JMCNEELY@UTCVM.BITNET
-----------[000038][next][prev][last][first]----------------------------------------------------
From:      watrous@athos.rutgers.edu (Don Watrous)  14-MAR-1989 14:34:13
To:        misc-security@rutgers.edu
Unlike their biological counterparts, computer viruses, worms, or
what-have-you can be designed to die should they escape their test
environment.  I would *hope* these test viruses have such precautions
included!

If R. Morris didn't think to take such precautions, I can't have much
sympathy for him.

Don
-- 
uucp:   {ames, cbosgd, harvard, moss}!rutgers.edu!watrous
arpa:   watrous@aramis.rutgers.edu
-----------[000039][next][prev][last][first]----------------------------------------------------
From:      Xc60039@PORTLAND.BITNET (Douglas Howell)  14-MAR-1989 14:45:22
To:        Security@pyrite.rutgers.edu
  Hi all,
      I was wondering there might be anyone who might be able to send
me a copy of Fred Cohen's disertation on computer viruses?  I've tried
getting it thru the college's library but they have not gotten yet and
I really wonder if they can.  I was told that Mr. Cohen may be at the
U. of Cincinatti, but as of yet I have not had the chance to confirm
that.  Anyone who has a copy of the disertation and is willing to send
me a copy of it let me know okay.  I've heard a lot about the paper and
would really like to read it.

Douglas Morrison Howell         | Disclaimer: Niether the U. nor my boss
Student of Engineering          |     knows what I'm saying so don't hold
University of Southern Maine    |     them responsible for my inept behavior.
-----------[000040][next][prev][last][first]----------------------------------------------------
From:      eugene@eos.arc.nasa.gov (Eugene Miya)  14-MAR-1989 14:54:14
To:        misc-security@ames.arc.nasa.gov
The discussion about networks, distributed security, etc. 
brings up several issues.  The issues are similar to the software
licensing issue of program generators (like YACC).  If programs
execute programs which perform "irresponsible" acts, who is responsible?
If daemons (written intentionally, obviously) do destructive acts,
can increasing levels of indirection eliminate responsibility?

The issue raised by program generators and licenses was who owns
the generated program.  The issue of daemons and program generators
and security is whether continued abstraction will become a problem.

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "Mailers?! HA!", "If my mail does not reach you, please accept my apology."
  {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
  "Post follow ups.  Contribute to network noise."
-----------[000041][next][prev][last][first]----------------------------------------------------
From:      <DAWSONM@IUBACS>  14-MAR-1989 14:55:46
To:        SECURITY@OHSTVMA
Hello,

        My name is Mark Dawson. I am a student of
Folklore and a computer consultant at Indiana
University. I am currently working on a
folklore project collecting computer folklore.
I am sending this letter to several listservers
to request contributions on the subject.

        What is computer folklore? I leave this to
you decide. Some subjects I am interested in
include:

Hacking (feats and/or tech.)
Phone Preaking (feats and/or tech.)
The "Electronic Tribunal"
Electronic executions

        These are just my particular interests, I
am taking a "shotgun" approach to the subject.
If you have any sort of computer story please
send it on, whether you think it is folklore or
not. It is not important if the information is
first hand, second hand or 12th hand. Nor is it
important -whether you may think the material
is true or not . Myth and legend has reached
the computer age, and has been going strong
for 20 years.

        All contributions are greatly appreciated.

Please send information to:
Mark Dawson     bitnet:  DAWSONM@IUBACS
ACCESS MicroCenter
IMU 059b
Indiana University      1(812)335-0910
Bloomington, In. 47405

This message has already been posted to the FOLKLORE list, please
feel free to forward this to any other list though.

Thank you
M. Dawson
-----------[000042][next][prev][last][first]----------------------------------------------------
From:      hollombe@ttidca.tti.com (The Polymath)  14-MAR-1989 19:34:14
To:        misc-security@sdcsvax.ucsd.edu
}    A friend of mine (without access to news) plans to write a survey
}paper on network security techniques.  Does anyone have any good references
}they could recommend?

DOD 5200.28-STD     Department of Defense Trusted Computer System
		    Evaluation Criteria, December 1985
		    (aka "The Orange Book")

NCSC-TG-005, v1     National Computer Security Center Trusted Network
		    Interpretation of the Trusted Computer System
		    Evaluation Criteria, 31 July 1987
		    (aka "The Red Book")

Both available for a minimal fee from the U.S. Government Printing Office
in Washington, D.C.

-- 
The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com)  Illegitimati Nil
Citicorp(+)TTI                                                 Carborundum
3100 Ocean Park Blvd.   (213) 452-9191, x2483
Santa Monica, CA  90405 {csun|philabs|psivax}!ttidca!hollombe
-----------[000043][next][prev][last][first]----------------------------------------------------
From:      Keith Natschke <9070NATSCHKE@MUCSD.BITNET>  14-MAR-1989 19:54:14
To:        security@pyrite.rutgers.edu
[Moderator injection: Replies to him, pls..   _H*]

Hello,
   I'm interested in any information anybody has on DEC's VAX Encryption. As an
educational site we can obtain it for just the cost of the media and
documentation under DEC's CSLG program. We would be using it for encryption of
confidential data such as payroll information. I'm mostly interested in:

  1. How well does it work?
  2. Is it easy to use?
  3. Has anybody had any problems with it?
  4. Can it be called from a program to encrypt specific fields in a file?
  5. How is the key given to programs accessing the data?

Thanks in advance!

MM      MM   UU      UU         Keith S. Natschke         Analyst/Programmer
MMM    MMM   UU      UU         Marquette University      Systems & Programming
MMMM  MMMM   UU      UU         Computer Services Division
MM MMMM MM   UU      UU         517 N. 14th Street
MM      MM   UU      UU         Milwaukee, WI  53233
MM      MM    UUU  UUU          Phone: (414) 224-3765
MM      MM     UUUUUU
                                BITNET:   9070NATS@MUCSD
Marquette    University         INTERNET: 9070NATS%MUCSD.BITNET@CUNYVM.CUNY.EDU
                                UUCP:     ...psuvax1!mucsd.bitnet!9070nats
-----------[000044][next][prev][last][first]----------------------------------------------------
From:      ssr@cos.com (Dave Kucharczyk)  14-MAR-1989 20:14:15
To:        misc-security@uunet.uu.net
stolen from sci.electronics:

  From the "Security" column of the February/March 1989 issue of
  _Retailing Technology & Operations_, a supplement to
  _Women's Wear Daily_/_Daily News Record_.
  Reprinted without permission.

MEET MISS ANNIE DROID

By Hassell Bradley

    Denver (FNS) -- Don't look now, but that snazzy looking mannequin over
there may be watching you -- and eavesdropping too.  With a camera in her
eye and a microphone up her nose, Anne Droid is the latest weapon in the
growing arsenal of antishoplifting technology.

    Jerry Gutierrez, who owns Anne Droid Mannequins, a nationally known
mannequin repair firm here, has developed a surveillance system that shoots
videotape through a mannequin's eye and ties in to closed circuit TV
networks.

    Besides its potential for spying on thieving shoppers or employees, the
system also could be used to record customers' reactions to new products.
According to Gutierrez, it fits into any type or size of mannequin head
-- infant or adult -- as long as there is an eye opening of one-half inch.
    In the past two years Gutierrez has perfected Annie, named his company
Anne Droid (he credits "Start Trek" with inspiring the name) and initiated
patent proceedings.

    Although he manufactures mannequins himself, Gutierrez designed the
surveillance system to fit just about any style mannequin a visual
merchandiser wants.

    Gutierrez manufactures the various glass and metal fittings for his
surveillance system.  They include a special camera carriage, acrylic
eyeballs through which the video camera films, special tubes, and contact
lenses.

    "I went to an optometrist and had a prescription written out for exactly
what I wanted for the eyeball," he said.  "Then I went to a lens cutter and
had him grind the lenses for me.  But I soon learned to do that for myself."

    The camera has automatic iris control and automatic focusing, so every-
thing is in focus within a range of lights and distances.  Once Annie is
installed inside a mannequin, the result is a fixed, closed circuit TV
camera that shoots only in black and white.

    Gutierrez said he's received a positive reception from the stores he's
shown the system to, but none have bought it yet.

    Peter Berlin, who runs a shrinkage consulting firm in Jericho, N.Y.,
was skeptical.  "I want people to know that we have cameras," he pointed out.
"I want to prevent theft, not detect it.  I want a camera capable of shooting
in more than one place at a time."

    Gutierrez maintained this device is intended to keep watch over specific,
troublesome areas that the sweep cameras may be missing.  "Anne Droid is not
meant to be a full system," he noted.  "It's meant to enhance dead spots
-- for example, if you want to watch a particular cash register."
 
    The system shoots videotape in real time and can be hooked up with most
VCRs, Gutierrez said.  He suggested, however, that it be used with surveil-
lance systems, which normally use time-lapse VCRs.

    The microphone, which is part of the camera, has a range of about 10
feet, depending upon background noise.

    "Most people believe, and they are correct, that it is illegal to record
a private conversation.  However, when a conversation takes place in a public
setting, it can no longer be deemed private.  Annie makes it possible for
retailers to listen to customers discuss new products or services a store
offers.  Annie could be installed in dressing rooms, or at counters.
And she would be ideal at trade shows."

    Gutierrez also can install Annie "blind:" (sic) After employees see
certain mannequins have cameras in them, he can make all the mannequins look
as though they too contain the system.

    Basic price, including the camera, four-inch monitor and 66 feet of
cable, runs between $1100 and $1200.  Including a Decter, Co. mannequin,
it would be $1800.  The cable length can be extended to 198 feet, but coaxial
cable must be used if the cable has to be any longer.  Annie hooks up to most
closed circuit TV systems.
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 15:09:39 GMT
From:      Housley.XOSMAR@XEROX.COM
To:        misc.security
Subject:   Re: Question on block ciphers

Jim Kirkpatrick:

RSA provides authentication when the blocks are enciphered with the private
key of the originator.  RSA provides confidentiality when the blocks are
enciphered with the public key of the recipient. 

There is common technique for getting both authentication and
confidentiality of messages longer than the "block size" (200 digits in
your example).  First, encipher the message in a traditional block chaining
cipher (like DES CBC).  Then, take the key and IV used to encipher the
message and encipher them twice with RSA -- once with the private key of
the originator and once with the public key of the recipient.  This give
authentication and confidentiality of the entire message.

The DARPA privacy-enhanced electronic mail (RFC 1040) uses this scheme.

Russ

-----------[000046][next][prev][last][first]----------------------------------------------------
From:      <PGOETZ@LOYVAX.BITNET> (If it doesn't kill you, it's good for you.)  15-MAR-1989  3:26:13
To:        security@pyrite.rutgers.edu
        Regarding root/etc/passwd:  Is there a known algorithm of
reasonable running time that can decrypt passwords from passwd?  (Not
encode random combinations & compare the result, but work with the
encrypted text to find the plaintext.)  Seems an important question to me.

Phil Goetz
PGOETZ@LOYVAX.bitnet
-----------[000047][next][prev][last][first]----------------------------------------------------
From:      eugene@eos.arc.nasa.gov (Eugene Miya)  15-MAR-1989  3:32:19
To:        misc-security@ames.arc.nasa.gov
>In fact, according to published reports the Computer Virus Industry
>Association

Who really is this group?  They appeared in the paper in prominence
during the November Worm.  What makes anyone think they can be trusted?
Or are they a reactionary group?

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "Mailers?! HA!", "If my mail does not reach you, please accept my apology."
  {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
  "Post follow ups.  Contribute to network noise."
-----------[000048][next][prev][last][first]----------------------------------------------------
From:      rja <rja@edison.cho.ge.com>  15-MAR-1989  3:34:18
To:        security@uunet.uu.net
I am looking for information on the Sun Workstations that 
have a rated security in the OS and that have passed 
Tempest.

Among the areas that I am interested in are:
  
  usability as compared with the standard Sun workstations
  ballpark cost differences
  the actual rating of SunOS by the NCSC or other agencies
  availability of such systems
  ability to connect to fibre-optic ethernets

I imagine that these aren't of very general interest, so if people
will Reply to me at one of the addresses below, I will summarise to
the net.  If you don't wish your reply quoted in my net summary,
please clearly indicate that in your mail.

Thanks
______________________________________________________________________________
         GE-Fanuc North America, Charlottesville, VA, USA 22906

Internet (preferable):         rja@edison.CHO.GE.COM  
UUCP    (if you must):         ...uunet!virginia!edison!rja 
______________________________________________________________________________
-----------[000049][next][prev][last][first]----------------------------------------------------
From:      Yuko Murayama (+44_1_387_7050 ext.3695) <Y.Murayama@purple.cs.ucl.ac.uk>  15-MAR-1989  7:38:05
To:        misc.security@purple.cs.ucl.ac.uk
Cc:        murayama@purple.cs.ucl.ac.uk
Could anyone give me the pointers to papers or books which present
a good survey on existing symmetric and asymmetric encryption
algorithms, please?  I would like to know their pros and cons.

Yuko Murayama
Dept of Computer Science,
University College London
-----------[000050][next][prev][last][first]----------------------------------------------------
From:      gwyn@brl.mil  15-MAR-1989  7:43:20
To:        security@pyrite.rutgers.edu
There is no credible way to assess the true cost of that worm incident.
For example, it is possible that the damage at BRL might have slipped
improvements to armored fighting vehicles by a week.  What would be the
true cost of that, anyway?  Dollars aren't a sufficient measure.
-----------[000051][next][prev][last][first]----------------------------------------------------
From:      lfoard@wpi.wpi.edu (Lawrence C Foard)  16-MAR-1989  0:16:54
To:        misc-security@husc6.harvard.edu
Remember on a PC unless there is hardware with a lock&key any one can still do
anything they want. This software will certainly slow people down but I
wouldn't trust it any more than a mainframe with public access. Even if DOS
doesn't recognize the hard drive it is still possible to write software to
access any section of the hard drive. The Encryption option may provide some
more protection but I have seen programs that will let you crack DES
encryption in about 30 minutes. 

Suppose this system has a UNIX like password file and you have just failed a
course and your grades are on this system.... Reading data from the hard drive
while not easy isn't that difficult. You happen to have an account on the
machine so you setup a large file with known contents, and take out your DES
cracker. 30 minutes later you have the encryption key, search the hard drive
for the password file change the system administrator password to nothing.
Login and pass the course.... Actually breaking into the system would take
some work but what if the person just wanted to erase the hard drive? Then it
is only necessary to write a lots of garbage data onto it. Unless the PC is
behind locked doors I wouldn't trust anything important to this system. 

Now for something completely different...

At least this isn't as bad as FAX documents being legally binding, I wonder how
long it will take for some one to realize they can undetectably forge legally
binding documents? Lets say you have just failed a course and you feel like
getting back at the "evil" prof? Fortunitly your father law firm (Leech and
son ambulance chasers) happens to have a board for there computer to transmit
fax documents. You find all the paper work the FBI would fax to your local
police department to have a child molester arrested, cut and paste a bit and
fax it down to the police station. Since phone calls don't tell where they are
coming from they will not realize that the documents are bogus until they
deliver the "child molester" to the FBI. And they will never be able to find
out who faxed them the documents.

-- 
Disclaimer: My school does not share my views about FORTRAN.
            FORTRAN does not share my views about my school.
-----------[000052][next][prev][last][first]----------------------------------------------------
From:      ishikawa%ultra.DEC@decwrl.dec.com (Jim Ishikawa, DTN_293_5054)  16-MAR-1989  3:28:11
To:        security@pyrite.rutgers.edu
It is possible to use encryption to increase the assurance that you can
extend the trusted path beyond  terminal servers to hosts.  This can be done
without changing existing network protocols.  Along with some node
authentication capabilities, data-link layer encryption can provide
integrity protection and controlled access analogous to hardwired serial
links.

Jim Ishikawa
DEC
-----------[000053][next][prev][last][first]----------------------------------------------------
From:      PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet  16-MAR-1989  3:32:26
To:        security%ubvm.bitnet@Hamlet.Bitnet
>A displayed number on the card changes every so
>many seconds; to authenticate you simply type in the current number and
>the system can authenticate you since it is time synced.

How many seconds?  Does this rely upon a chip in the card keeping time accurate
to within a number of seconds over an operating lifetime of possibly years?  If
so, it better be more accurate than my digital watch -  and that's a good one.
I wouldn't trust it near the edges of its time spans.  I don't see how else it
can work unless it talks to the host to check that they're synched, which
severely compromises the effectiveness.

Peter Scott (pjs@grouch.jpl.nasa.gov)
-----------[000054][next][prev][last][first]----------------------------------------------------
From:      ddp@topaz.rutgers.edu (BiG WavE DavE)  16-MAR-1989  4:11:02
To:        misc-security@rutgers.edu
Hiya folks,

Remember that virus that hit almost every 'puter on the
Arpanet last fall??  Well, I'm writing a paper on the debate
on whether or not the source code of that virus (or any other virus
affecting any other computer/network) should be accessible by the
general public.  I'll actually be defending one of the sides.

Anyway, I need facts from both sides of the issue and I'm asking the
general NET to help me out.  So if you think you're qualified to...
shall we say..."comment" on the issue, please send me e-mail.  Remember, I
need FACTS.  Any pointers to any published articles about the subject
would also be greatly appreciated.  (Yes, I will be doing my own
research as well.)

Anyone wishing a copy of the finished paper can send me e-mail.

Thanx in advance...

-WavE (a.k.a. David Pascua)
ddp@topaz.rutgers.edu
...!rutgers!topaz.rutgers.edu!ddp

[Moderator add-on: replies ONLY to him, please.  There's already been quite
enough flaming about this issue...   _H*]
-----------[000055][next][prev][last][first]----------------------------------------------------
From:      <PGOETZ@LOYVAX.BITNET>  16-MAR-1989  6:54:29
To:        security@pyrite.rutgers.edu
Can someone tell me what the encryption algorithm is for:

        1. UNIX crypt (the password encryption)
        2. DES

Phil Goetz
PGOETZ@LOYVAX.bitnet
-----------[000056][next][prev][last][first]----------------------------------------------------
From:      rogers@marlin.nosc.mil (Rollo D. Rogers)  16-MAR-1989  6:57:29
To:        BORYNEC@bnr.ca
Cc:        security@rutgers.edu
Why not take the same precautions you would for software of unknown
pedigree before you let it loose on your fixed disk system?

  REgards, RollO~~
-----------[000057][next][prev][last][first]----------------------------------------------------
From:      Don Chiasson <G.CHIASSON@xx.drea.dnd.ca>  16-MAR-1989  7:13:25
To:        security@pyrite.rutgers.edu, jimkirk@outlaw.uwyo.edu
Cc:        G.CHIASSON@xx.drea.dnd.ca
     DES only has a 56 bit key - not 64 bit, which a number of people
feel does not give sufficient security.  It is possible to develop a
system similar to DES with more bits, which the original
implementation had.  If more security is desired, the data could be
double encrypted with two DES boxes with different keys in series
(somehow my gut feeling does not like this), or with two DES boxes in
parallel (e.g. one does the odd bits and the other the even bits).
Assuming there are no trapdoors in DES, this would give a 112 bit key
encryption without having to develop a new algorithm.
		Don
-----------[000058][next][prev][last][first]----------------------------------------------------
From:      Don Chiasson <G.CHIASSON@xx.drea.dnd.ca>  16-MAR-1989  7:15:47
To:        security@pyrite.rutgers.edu, tihor@acf6.nyu.edu
Cc:        G.CHIASSON@xx.drea.dnd.ca
     The classic reference on letter probabilities in English is Shannon,
"Prediction and Entropy of Printed English", Bell Systems Telephone
Journal, Vol 30 no 1, pp.50-64, January 1951.  An old book I have,
"Information Theory and Coding", Abramson, 1961 gives the following
information:
 -	For a 27 letter equiprobable alphabet (A-Z,space) with no inter
	symbol dependency, the entropy or per symbol information content 
	of the source is 4.75 bits/symbol.
 -	If the probabilities of the symbols are included, ie ETAOIN....
	the entropy becomes 4.03 bits/symbol.
 -	If each letter depends only on the previous symbol, we
	get 3.32 bits/symbol; if on the previous two symbols,
	approximately 3.1 bits/symbol.
 -	If the dependence is on all the preceding text, it is between
	0.6 and 1.3 bits per symbol.  One bit per symbol is often
	assumed.  In other words given a long string of text, there is
	a 50% chance you can correctly guess the next letter.  
     Thus using a long and correctly spelled English word does not give a
great deal of password security.  Violate one or more of these conditions
and the problem of guessing a password is much more difficult.

			Don
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 13:01:31 GMT
From:      greenber@utoday.UUCP
To:        misc.security
Subject:   Who really is CVIA?

The CVIA has a rather interesting background.  I'm *not* a member of
the CVIA, althouhg I am an anti-virus vendor.  The head honcho of the
CVIA is a fellow named John McAfee.

Mr. McAfee is an anti-virus vendor as well.  His estimates of the virus
infiltration and the damage caused by virus infiltration is a bit higher
than I'm comfortable with.  When speaking with the press, he oftentimes
gets quoted using some rather extraodrinary numbers and facts, based upon
his theories of "non-reporting" sites.

My belief if that you can't say something like:  "Only 15% of the sites
with damage are talking about it" and then extrapolate out for the so-called
missing sites.  I hold his numbers in disbelief.

Ross M. Greenberg
Author, FLU_SHOT+

Ross M. Greenberg
UNIX TODAY!             594 Third Avenue   New York   New York  10016
Review Editor           Voice:(212)-889-6431  BBS:(212)-889-6438
uunet!utoday!greenber   BIX: greenber  MCI: greenber   PCMagNet: 72241,36

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 16:17:34 GMT
From:      stev@VAX.FTP.COM
To:        misc.security
Subject:   Unix passwords

*        Regarding root/etc/passwd:  Is there a known algorithm of
*reasonable running time that can decrypt passwords from passwd?  (Not

yes.

(actually, it *may* not generate the original password, but it *will*
generate one that will encrypt into the same thing.)

scary, isnt it?:)

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 16:27:27 GMT
From:      Hoffman.ElSegundo@XEROX.COM
To:        misc.security
Subject:   Theft-proof car lock?

>From: Rodney Hoffman <Hoffman.ElSegundo@Xerox.com>

This piece ran in 'Business Week' magazine, March 13, 1989, p. 77:

            TV TECHNOLOGY MAY KEEP CARS SAFER FROM THIEVES
  
   Looking for a better car security system?  Take another look at your TV.
   Using the same technology that sharpens TV images, GTE Corp. scientists 
   have up with a new theft-proof locking system.  The device uses the
   properties of SAW -- surface acoustic waves -- to activate a tiny coil
   embedded in a car key.  As the key turns to open the door or start the
   engine, the coil sends out a coded digital signal needed to unlock or 
   start the car.  GTE makes similar SAW filters to lock in color TV tuners 
   on each channel.

   GTE's auto-lock system, called SAFE for surface acoustic filter encoding, 
   has the advantage of being completely passive:  There are no codes to
   memorize or alarms to disarm.  And unlike other antitheft locks, SAFE 
   needs no electrical contact -- or even teeth on the key.  Eventually, 
   keys for individual drivers could be encoded to automatically adjust 
   the seats and mirrors.  So far, GTE has gotten "a strong response" in
   Detroit, says Scott L. Atkinson, marketing specialist with GTE's Elec-
   tronic Components & Materials Div., who thinks auto makers may offer
   SAFE within two years.  Also eyeing the system, says Atkinson, are 
   foreign carmakers and major U.S. car insurers, who are battling $6 
   billion a year in U.S. car-theft losses.

-----------[000062][next][prev][last][first]----------------------------------------------------
From:      Root Boy Jim <rbj@nav.icst.nbs.gov>  17-MAR-1989  1:57:10
To:        gwyn@smoke.brl.mil
Cc:        misc-security@uunet.uu.net
As far as those "Cipher" lox (five bidirectional rocker switches) go, my
favorite technique is to take a piece of chalk and rub it over all the
ribs on the switches. When you come back a few days later, all the buttons
used for the combination have been wiped clean. That leaves you only
24 (4*3*2*1) instead of 5040 (10*9*8*7).

	Catman Rshd <rbj@nav.icst.nbs.gov>
	Author of "The Daemonic Versions"
-----------[000063][next][prev][last][first]----------------------------------------------------
From:      deh@eng.umd.edu  17-MAR-1989  2:05:05
To:        nichols@cbnewsc.att.com
Cc:        security@pyrite.rutgers.edu
The number of combinations can be cut down quite a bit by spraying 
or dusting the button tops with an organic dye (or whatever) that 
will display pretty colors when illuminated with UV light. I always
prefered a coupld of strange organic dyes used in dye lasers, but 
they are expensive, and a lot of comon household things work just
as well (the proof is left as an exercise for the reader). For a 
portable UV light source, you can get fancy, but I like the little
EPROM eraser lights. Small, portable, and intense. A battery powerd
device would be better of course if 120VAC is not available in the
target area. 

In any case, the buttons without powder left on them are the 
ones that you want to play with. This works great in elevators
that have button code systems in them for after hours use. The 
MIT Media Lab is a good example of such a facility (I wonder if
they still glow over there?). 

Doug
-----------[000064][next][prev][last][first]----------------------------------------------------
From:      <TOM@FANDM.BITNET> (Tom, Tech. Support)  17-MAR-1989  5:08:29
To:        security@pyrite.rutgers.edu
Must be a real well-liked management team that feels they need bulletproof
glass between them and the troops.

I hope this was more to protect from unauthorized access rather than to
protect from bullets.  If so, it sure is better than window glass, but, as
you state, overkill given the 3/4 inch plywood walls.  On the other hand,
those walls are tougher than you might think provided they are well built.
I wouldn't want to try kicking it in!

*        HAVE A GOOD DAY        *
*                               *
* Tom Mahoney                   *
* Computer Electronics Tech.    *
*                               *
* FRANKLIN & MARSHALL COLLEGE   *
* Computer Services             *
* Technical Support Center      *
* Lancaster, PA  17604-3003 USA *
* (717) 291-4005                *
* Bitnet Address: TOM@FANDM     *
*********************************
-----------[000065][next][prev][last][first]----------------------------------------------------
From:      att!ulysses!smb@research.att.com  17-MAR-1989  5:28:29
To:        att!misc-security
For the reasons that you name, and others as well, block ciphers are
not normally used straight.  What you want to look into are the DES
modes of operation; they're in FIPS 81, or ANSI X3.106.  There are other,
non-standard, modes as well.

For message-at-a-time operation, many people use ``cipher block chaining''.
It involves exclusive or-ing each input block with the output of the
previous step before encrypting.  That is, if C[i] is the ciphertext
from encrypting P[i], each step looks like this:

	C[i] = E(P[i] ^ C[i-1])

Decryption is the reverse:

	P[i] = D(C[i]) ^ C[i-1]

An initial value IV is used to start things off for block 1 when there is
no C[0].

There is still some chance of cut&paste here; refer to any standard work
on cryptography for details of the properties of this and other modes.
I suggest Davies and Price's ``Security for Computer Networks''.
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 04:00:02 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        misc.security
Subject:   Re: Unix passwords

>         Regarding root/etc/passwd:  Is there a known algorithm of
> reasonable running time that can decrypt passwords from passwd?

No, there's no known algorithm.

Oh, you want more?  Neglecting the salt for the moment, password-hashing
is done by repeatedly encrypting a constant string with the user's
password as the key.  The encryption algorithm used is DES.  Deducing
the password is therefore the same as the following:  given a known
plaintext (the constant), and a known ciphertext, find the key.  This
is equivalent to cracking DES, which has not been demonstrated to be
possible, at least to those of us who don't work for the NSA, the KGB,
or equivalent.  And, given that the encryption is repeated many times
(just to slow things down), the problem is harder yet.  Finally, even if
NSA can crack DES -- and that seems not improbable -- it's quite likely
that they require much more plaintext than 8 bytes.  (Unless, of course,
the S-box is really a trapdoor function, to which they have the matching
key.)

Two caveats.  First, the set of ASCII password doesn't come close to
exhausting the DES key space.  It isn't clear to me how much of a difference
that makes, since all bits in the key are settable.  Second, the password
hash salt function permutes the E-box; there has been evidence presented that
this weakens the encryption somewhat.  I have no idea if that would help
cryptanalysis in a practical sense, especially given the limited plaintext
available.

For details on how the password algorithm got to be the way it is, read
``UNIX Password Security'', R. Morris and K. Thompson, CACM, Vol. 31, No. 5
(May 1988), p. 484.

-----------[000067][next][prev][last][first]----------------------------------------------------
From:      deh@eng.umd.edu  17-MAR-1989 17:48:31
To:        jimkirk@outlaw.uwyo.edu
Cc:        security@pyrite.rutgers.edu
the way to get the address associated with a number is to call the 
phone company CNA (Customer Name and Address) bureau. this is used 
by various telco functions, and if you can get the phone number to
it they usually don't require any id, etc.

Otherwise, you will have to sweet talk the Business Office, or 
pretend that you are a long distance supplier and bullshit
the group that handles them (different from the business office)
into giving you the data. Doesn't sound too hard actually.

Doug
-----------[000068][next][prev][last][first]----------------------------------------------------
From:      "MARTIN J MOORE" <mooremj@uv4.eglin.af.mil>  17-MAR-1989 17:52:33
To:        "security" <security@pyrite.rutgers.edu>
Regarding the relative merits of marked and unmarked keys:

Our local PBS television station sends its members a key ring marked with 
*their* address and a code number (unique to each ring).  They keep a record
of the code numbers.  The idea is that the finder of a lost key ring will mail 
it back to the station, who will then forward it to the member.  If the key
ring is found by a dishonest person, there is no risk because there is no
other identifying information on the key ring.

(This of course assumes that the personnel at the PBS station are honest.
 But I'm willing to take my chances on that.)
-----------[000069][next][prev][last][first]----------------------------------------------------
From:      paul@csc_lons.arpa (paul@tb)  17-MAR-1989 18:07:19
To:        security@pyrite.rutgers.edu
     Back in the 70's there existed something called a "Lineman's Book" 
published by the local phone companies.  It cross refrenced name to address 
to telephone number.  It also cross refrenced by address and by telephone
number.  I believe it also included curcuit numbers dealing with the
phone line in question.  I was supplied to linemen and listed all (even
unlisted number) so the phone company people could do their work without
calling a controller every 20 minutes.  If this type of book still exists,
and I think it would, paying an underpayed lineman $20.00 for a 2 minute
look in "The Master Book".  If I remember the lore properly the lineman 
had to sign out the book in the morning, and return it when done with
his shift. 
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 14:12:58 GMT
From:      lg@computer-lab.cambridge.ac.uk
To:        misc.security
Subject:   Re: Fred Cohen

>      I was wondering there might be anyone who might be able to send
>me a copy of Fred Cohen's disertation on computer viruses?

I could have replied via private email, but I think this might be interesting
to the general public.

I made an enquiry to U. of Southern California where Dr. Cohen did his Ph.D.
USC Library replied that there was an indefinite hold on his thesis and could
not be released without further notice.

After I got this reply, I read in the newsgroup comp.risks that Do. Cohen
claimed he could supply the copy with a minimum fee.  I emailed his enquirying
whether the hold on his thesis has been lifted.  Didn't get any response.

A paper on the same topic can be found in the Proceedings of the 7th DoD/NBS
Computer Security Conf. 1984.
____________________________________________________________________________
| Li GONG (+44223-334650)     University of Cambridge, Computer Laboratory |
|                             Pembroke Street, Cambridge CB2 3QG, England  |
| InterNet/CSnet : lg%cl.cam.ac.uk@cunyvm.cuny.edu  (or @nss.cs.ucl.ac.uk) |
| UUCP : ...!ukc!nss.cs.ucl.ac.uk!cam-cl!lg   Bitnet/EAN : lg%cl.cam@ac.uk |
 ----------------------------------------------------------------------------

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 19:52:22 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        misc.security
Subject:   Re: Unix & DES

>         1. UNIX crypt (the password encryption)

See the Morris and Thompson paper in the November 1979 issue of CACM.

>         2. DES
Lots of places describe it; I recommend Davies and Price's book ``Security
for Computer Networks'', or Beker and Piper's ``Cipher Systems''.  The
latter includes the full text of the federal publication announcing it.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 20:22:34 GMT
From:      BRUCE@UMDD.UMD.EDU (Bruce Crabill)
To:        misc.security
Subject:   DES Breakability

Double encryption using DES (or anything else for that matter) gives you
an effective 57 bit key, not 112.  By doubly encrypting something, you are
just making it twice as hard to break, or one extra power of two.  It is
n**2 as much work, not n**n.

                                       Bruce

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 22:59:54 GMT
From:      scc@computer-lab.cambridge.ac.uk (Stephen Crawley)
To:        misc.security
Subject:   password grabbers

>Well, sure, if you're using micros as terminals, and the micros are
>publicly accessible or shared, then there are all kinds of possibilities
>for security cracking.

Granted.  However, zero knowledge authentication implemented in the
right way (e.g. with some sort of smart card) WOULD give security
against account stealing/password grabbing.  It wouldn't give you
secure communications ... but that is a different issue.

I'm not sure if I made it clear in my original posting, but a password
grabber could well reside in the comm's network.  Saying, "don't use
micro's as terminals ... " is not a solution.  

>In our environment the users who use public terminals seem to like the
>personalized password prompts, both for security and because they can be 
>cute.  All we claim for them is that they will sometimes defeat the most
>simple-minded password grabber programs

But unfortunately that is not our experience.  I'm talking about how the
problem can be solved.  Making it harder to steal passwords is not going 
to deter the determined hacker ... and our experience is that some hackers
are VERY determined.

>Now the method of attack has shifted to modern high-performance password
>guessing programs.

Actually, my feeling is that this is an easier problem to solve:
 
1)	Make the encrypted passwords inaccessible to normal users.
&
2)	Log failed login attempts.
&
3)	Stop users from setting their passwords to something that is
	guessable.  Use rules like: at least N characters, no words 
	in a dictionary, at least 1 non-alphabetic character, etc.
	
Point 1) means that the hacker grab a file of encrypted passwords and
feed them through a password guesser.  Instead the hacker has to try
each password guess with the login program, which will show up in 
your logs (hence point 2).  Point 3) means that the hacker is going to
have to try a LOT of password guesses.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 00:44:56 GMT
From:      gwyn@BRL.ARPA (Doug Gwyn (VLD/VMB) <gwyn@brl.arpa>)
To:        misc.security
Subject:   Re: Unix passwords

>        Regarding root/etc/passwd:  Is there a known algorithm of
>reasonable running time that can decrypt passwords from passwd?

None have been published.  (Actually, without looking into it in detail,
it might be possible that more than one password would produce the same
encrypted result, so such an "inverse DES" would compute A password, not
THE password.)

>     DES only has a 56 bit key - not 64 bit, which a number of people
>feel does not give sufficient security.  It is possible to develop a
>system similar to DES with more bits

LUCIFER differed from DES in other ways, too.

The often-heard suggestion that DES needs a longer key is always based
on the notion of making brute-force search of the entire key space
impractical.  However, that is by no means the only method of attacking
such a system; you should therefore not trust increased key length as
providing substantially more security.  If the 56-bit key space could
indeed be affordably searched in a modest amount of time with available
computer resources, then indeed it would be too short; a sufficiently
long key to render brute-force key searching impractical is NECESSARY
but not SUFFICIENT for secure encryption.

sci.crypt is probably a better newsgroup for cryptographic discussions.

[Moderator tack-on:  Agreed.  If we move the DES stuff there, traffic will
be more balanced between the respective lists.  Unfortunately it's harder
than I'm willing to deal with to forward the stuff from here to there on
a message-by-message basis, so look for a big lump of "the rest of this"
in sci.crypt soon.   _H*]

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 04:51:24 GMT
From:      deh@eng.umd.edu
To:        misc.security
Subject:   Re:  DES Breakability

As mentioned, you can make two (or more) passes through the DES
for additional security. Dons 'gut feeling' about this maybe not being
a good idea pertains I am sure to the possibility of patterns 
forming from the multiple runs through the data; this is possible
with a lot of crypto systems, and I would not be suprised if it
was the case with DES.

Note that knowing how many passes were made, and with what key
length (another GREAT variable you can use) is very important. It is not
easy to break things when you have no idea how many passes were made,
and what the key lengths were. 

Still, the best thing is the 300 meg disk pack, delivered to all of the
sites on the network by the boys in green armed to the teeth, containing
the oh_so_secure one time pad. The military actualy does this in some
special cases, and it really is a very good idea; it reduces a comm
and computer security risk (which they may not have a lot of experience 
in) to a straight forward physical security risk (which they have a 
lot more experience in and are more prepared to handle). Of course,
for a network of more than 20 or so sites, it DOES get to be a bit of
a bother. Also, if there is a lot of data moving, then you just want
to use the one time pad data as keys (but maybe VERY long ones!)
and run some normal encryption system. 

Anyone want to figure out how many packs (oppsss... Its 1989 now, 
lets use CD-ROMs) it would take to secure the internet?

Doug

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 16:32:00 GMT
From:      DLV@CUNYVMS1.BITNET
To:        misc.security
Subject:   Re: DES Breakability

Don Chiasson suggests applying DES twice. I just wish to remind that it has not
been shown that this differs from applying DES once with some third key (in the
appropriate jargon, we don't know whether it's a group). Although it is
generally believed to be the case, one should probably make appropriate
disclaimers when making such suggestions, etc, etc, ad naus...

Dimitri Vulis
Math Department
CUNY GC

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 15:25:52 GMT
From:      heilpern@BRL.MIL
To:        misc.security
Subject:   Re: Unix passwords

>        Regarding root/etc/passwd:  Is there a known algorithm of
>reasonable running time that can decrypt passwords from passwd?  (Not
>encode random combinations & compare the result, but work with the
>encrypted text to find the plaintext.)  Seems an important question to me.

To the best of my understanding, as stated in a few books I've read (the
titles escape me) the algorithm unix uses to encrypt passwords is irreversable,
letters being changed according to previous letters before change. Also,
the fact that ALL encryptions yield 13 characters (actually, 11 characters
and a two character key) seem to suggest this.

	Mark

-----------[000078][next][prev][last][first]----------------------------------------------------
From:      gwyn@brl.mil  22-MAR-1989 12:37:26
To:        security@pyrite.rutgers.edu
>It has often been said that DES *could* be broken by brute-force using
>lots of Cray-2 time and so on, and that the NSA caused the DES' key to
>be just short enough that they could break it but nobody else could.

If NSA can indeed break DES, it's because they know more about cryptanalysis,
not because they have bigger, faster computers for brute-force searching the
key space.

So, increasing the key size is not necessarily an effective countermeasure.
-----------[000079][next][prev][last][first]----------------------------------------------------
From:      Steve Lesh (ISC | howard) <lesh@brl.mil>  23-MAR-1989  0:32:00
To:        unix-wizards@brl.mil, info-unix@brl.mil
Cc:        security@pyrite.rutgers.edu
	Thanks to all for the rather amazing quantity of responses to my
request for the security validation programs mentioned in the Kochan and Woods
book on UNIX System Security.  I NOW HAVE THE PROGRAMS.  

	I think I responded to all requests to forward these programs.  I
would be willing to act as a manual file server providing things don't get
out of hand.  Anyone knowing anything about the legal implications of posting
these programs to uunet archives might want to look into archiving the above.
There certainly seemed to be a lot of interest!

	Thanks again for the all the responses to my request.
-----------[000080][next][prev][last][first]----------------------------------------------------
From:      gwyn@brl.mil  23-MAR-1989  1:43:30
To:        security@pyrite.rutgers.edu
>Will virus killing programs kill daemons by mistake?

This is a very important point that deserves reemphasis.
There is NO practical way to tell the difference between
a legitimate utility program and a virus program.  If the
system privileges permit certain operations and my program
performs those operations, it might be for a legitimiate
function or it might be that I am maliciously exploiting
a loophole in the system protection rules.  It may even
be in the shadowy area in-between, for example if I remove
a huge scratch file that is keeping my application from
getting enough disk space to perform its job.  Should I be
removing the scratch file or not?  That's a matter of local
system administrative policy.  So far as system security is
concerned, if the system permits it then it is legitimate.

There are two things that can go wrong.  A perfectly secure
system can be misadministered, so that users are given more
capabilities than intended.  Or, the system security rules
and implementation may have inadvertent loopholes.  The
combination of both factors was involved in the Internet
worm incident.

Automatic "virus killers" are completely misguided.  If you
know enough to identify inadvertent security loopholes or
errors in system administration, you should be in a position
to get them fixed.  If your virus killer acts on any other
grounds, then it will interfere with perfectly legitimate
applications.
-----------[000081][next][prev][last][first]----------------------------------------------------
From:      scarter@caip.rutgers.edu (Stephen M. Carter)  23-MAR-1989  5:36:12
To:        misc-security@rutgers.edu
>so they installed bullet-proof
>glass in those windows. The trouble is, the windows are set in a wall
>made of nothing more than 3/4" plywood and 2x2's.

I don't know what they make out on the factory floor, but if it has
anything that uses robot arms, milling machines, and the like, *I* would
feel a lot better on having that nice thick and hefty glass around me
than standard plate glass.   A small metal object can be thrown a fair
distance coming out of some machines.  If that object hits a large plate
glass area, watch out.

They may not be more secure, but a lot safer.
-----------[000082][next][prev][last][first]----------------------------------------------------
From:      GREENY <MISS026@ECNCDC.BITNET>  23-MAR-1989  7:06:46
To:        <security@pyrite.rutgers.edu>
> I'm looking for a callback program...

Hmmm...I have never seen/heard of such a beastie, as there are a variety of
modems that will perform the same function, only with a much lower computer
CPU usage rating than a program would have (i.e. the modem does most of
the work...freeing up more CPU cycles...)

Also, since their passwords are in EEPROM inside the modem, they are less
vulnerable to attack than are passwords stored on a disk pack attached to
a UN*X box..

Bye for now but not for long
Greeny

BITNET: MISS026@ECNCDC
Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU
-----------[000083][next][prev][last][first]----------------------------------------------------
From:      Housley.XOSMAR@xerox.com  23-MAR-1989 20:36:26
To:        security-request@pyrite.rutgers.edu, jimkirk@outlaw.uwyo.edu
Cc:        Housley.XOSMAR@xerox.com
Jim Kirkpatrick:

RSA provides authentication when the blocks are enciphered with the private
key of the originator.  RSA provides confidentiality when the blocks are
enciphered with the public key of the recipient. 

There is common technique for getting both authentication and
confidentiality of messages longer than the "block size" (200 digits in
your example).  First, encipher the message in a traditional block chaining
cipher (like DES CBC).  Then, take the key and IV used to encipher the
message and encipher them twice with RSA -- once with the private key of
the originator and once with the public key of the recipient.  This give
authentication and confidentiality of the entire message.

The DARPA privacy-enhanced electronic mail (RFC 1040) uses this scheme.

Russ
-----------[000084][next][prev][last][first]----------------------------------------------------
From:      WHMurray@dockmaster.arpa  23-MAR-1989 22:25:22
To:        security@rutgers.edu
>Am I missing something in the algorithm, that "binds" blocks in   
>some way to prevent this, or is there an underlying assumption    
>that external means will be taken to glue the blocks in some way? 
>Clearly you could include block numbers inside each block to      
>ensure block sequence and reception of all blocks, but this does  
>notsolve the issue of authentication of signed messages           
                                                                   
Yes, you are missing something, but it is not in the DES Standard. 
DES is a "block" cipher, i.e., it is designed to encode 64 bit     
blocks.  Of course, the world is not made up of convenient 64 bit  
blocks, so there is another standard that describes the safe ways  
to compose it into mechanisms for messages of arbitrary length.    
Most of these add so much complexity as to be more secure than the 
DES primitive.                                                     

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114                          
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840                
-----------[000085][next][prev][last][first]----------------------------------------------------
From:      WHMurray@dockmaster.arpa  24-MAR-1989  0:06:03
To:        security@rutgers.edu
>Having not studied the DES in great detail yet, how easy is it to  
>increase the key to 64 bits or more?                               
                                                                    
It is easy to achieve any effective key length that you desire.  IBM
uses a triple encryption technique in its 3848 channel-attached     
crypto engine to achieve an effective key length of 112 bits.       
(Three encryption steps are used in such a way that if the key is   
chosen with 56 bits repeated twice, then steps 1 and 2 cancel each  
other out.  This permits compatability with the standard 56 bit     
software implementation.)                                           
___________________________________________________________________ 
William Hugh Murray                     216-861-5000                
Fellow,                                 203-966-4769                
Information System Security             203-964-7348 (CELLULAR)     
 DOCKMASTER 
2000 National City Center               MCI-Mail: 315-8580          
Cleveland, Ohio 44114                   TELEX: 6503158580           
                                        FAX: 203-966-8612           
21 Locust Avenue, Suite 2D              Compu-Serve: 75126,1722     
-----------[000086][next][prev][last][first]----------------------------------------------------
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)  24-MAR-1989  1:07:21
To:        misc-security@att.att.com
The first step of DES encryption is to convert the 56-bit key into 16
48-bit subkeys.  This step is done by a series of shifts (rotates, really)
and permutations.  Presumably, other algorithms could be used to expand
any reasonably-short key to 768 bits, or one could even specify a 768-bit
key directly.  I've seen something of the sort proposed in Cryptologia,
but I'm not qualified to evaluate the merits of the proposal.  Certainly,
there are weaknesses to be avoided; for example, if all 16 subkeys are
the same, the algorithm is much easier to crack.  There are other patterns
even in standard DES that can give rise to undesirable subkey structures
(i.e., semi-weak keys).

The controversial section is the S-box.  It's undisputed that (a) NSA changed
it; (b) there are regularities in it; (c) NSA has admitted to some of the
design principles; and (d) no one has yet (publicly) found any way to use
any of these quirks.  It may even be true that these changes make DES
stronger.  Meyer and Matyas (in ``Cryptography:  A New Dimension in Computer
Data Security'') note that random S-boxes take fewer logic elements to
implement than do the standard one, when expressed as the sum of Boolean
minterms.  They conjecture that this is significant.  (Note:  Meyer and
Matas work for the group at IBM that designed DES in the first place.
This may or may not make them credible; it does speak well of their
knowledge.)

> RSA keeps sounding better and better, if it could only be made reasonably
> quick.

Given recent progress in factoring, are you sure this is a good idea?

I've redirected follow-ups to sci.crypt.
-----------[000087][next][prev][last][first]----------------------------------------------------
From:      att!iexist!nichols@research.att.com  27-MAR-1989 22:49:35
To:        deh@eng.umd.edu
Cc:        security@pyrite.rutgers.edu
WRT using fluorescent dye to determine used vs. unused buttons, I
suspect that a solution of ordinary laundry detergent would be the most
readily available.  The brighteners glow brilliant white under UV.

For Simplex locks, however, who needs it!?  It only takes 1 to 2 minutes
of manipulation to identify used and unused buttons, with no apparatus,
power source, or even ambient light required.  In the (uncommon) event
that all the buttons were used, there are 541 combinations to try.  If
less, the math is definitely on your side.

                   #buttons       #comb
                   5 of 5         541
                   4 of 4         75
                   3 of 3         13

					Bob Nichols
					nichols@iexist.att.com
-----------[000088][next][prev][last][first]----------------------------------------------------
From:      "Katherine J. Dante" <kdante@note.nsf.gov>  28-MAR-1989  0:32:14
To:        James (J.G.)Borynec <BORYNEC@bnr.ca>
Cc:        security@rutgers.edu
Since computer stores have the ability to re-shrink wrap software and allow
customers to try the software out, I am not sure that shrink wrapping does
any more than assure you that the price on the wrap is the price the store
wants to charge for whatever is in the wrap.  You certainly cannot tell
whether you are getting all the disks/documentation that the manufacturer
intended.  And you have no assurance that some smart-aleck didn't plant a
virus while "checking out" the program with his own disk.
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Mar 89 00:19 EST
From:      WHMurray@dockmaster.arpa   28-MAR-1989  0:38:36, WHMurray@dockmaster.arpa
To:        security@rutgers.edu, security@rutgers.edu
>I heard once that the research behind parts of the algorithm were
>still classified.

IBM's discussion of how and why the S-boxes were selected was
classified.  However, all of the algorithm, including the S-boxes,
is public.

RSA's MailSafe, recently approved for use by the Internet
Activities Board, implements a DES/RSA hybrid with the speed of the
DES and all of the properties of the RSA.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
-----------[000090][next][prev][last][first]----------------------------------------------------
From:      rjg@sialis.mn.org (Robert J. Granvin)  29-MAR-1989  7:05:51
To:        misc-security@uunet.uu.net
Quite some time ago, someone posted an address and telephone number of
where to locate the "Rainbow Volumes".  Would some kind soul email me
that information?

Thanks.

-- 
       Robert J. Granvin           "Mueslix: A natural blend of oats, barley,
 National Information Services      octopi, Toyotas, cement and small furry
       rjg@sialis.mn.org            animals too slow to escape our field
{amdahl,hpda}!bungia!sialis!rjg     agents."   --'corsair'
-----------[000091][next][prev][last][first]----------------------------------------------------
From:      pj@hrc63.co.uk (Mr P Johnson "Baddow")  29-MAR-1989  9:00:34
To:        misc-security@ukc.ac.uk
Yeah: a couple of things come to mind wrt unchanged combinations.  My
parents once stayed in a London hotel with punched cards for room keys.
If you lost your card (or when you left) they just changed the combo
and issued a new pair of "keys".  At one point they had difficulty, so
the maid came and unlocked their room with the master key.  You could tell
it was the master key because it had ALL its holes punched.

In a similar vein, in "Surely your joking Mr Feynmann", Richard Feynmann
describes how he cracked safes at Los Alamos.  One of the safes was
a super-strong secure safe installed by a Brass-Hat.  When the safe was
removed they had to open it.  The local locksmith found that the
Brass-Hat had never bothered to change the factory combo.

Paul.

[Moderator add-on: The punched cards were probably Yaletronics locks.  If
you want, I can dig up a generalized writeup on these hotel systems I did
a while back.  However, the master key would be something other than
all-holes-punched.  Unless this was something a good deal more stupid than
a Yaletronics...  _H*]
-----------[000092][next][prev][last][first]----------------------------------------------------
From:      utoday!greenber@uunet.uu.net  30-MAR-1989 22:17:22
To:        security@pyrite.rutgers.edu
The CVIA has a rather interesting background.  I'm *not* a member of
the CVIA, althouhg I am an anti-virus vendor.  The head honcho of the
CVIA is a fellow named John McAfee.

Mr. McAfee is an anti-virus vendor as well.  His estimates of the virus
infiltration and the damage caused by virus infiltration is a bit higher
than I'm comfortable with.  When speaking with the press, he oftentimes
gets quoted using some rather extraodrinary numbers and facts, based upon
his theories of "non-reporting" sites.

My belief if that you can't say something like:  "Only 15% of the sites
with damage are talking about it" and then extrapolate out for the so-called
missing sites.  I hold his numbers in disbelief.

Ross M. Greenberg
Author, FLU_SHOT+

Ross M. Greenberg
UNIX TODAY!             594 Third Avenue   New York   New York  10016
Review Editor           Voice:(212)-889-6431  BBS:(212)-889-6438
uunet!utoday!greenber   BIX: greenber  MCI: greenber   PCMagNet: 72241,36
-----------[000093][next][prev][last][first]----------------------------------------------------
From:      rja <rja@edison.cho.ge.com>  30-MAR-1989 23:01:11
To:        misc-security@edison.cho.ge.com
I got several good reponses to my request for information
on secure Sun workstations.  In particular,

Daniel Faigin <faigin@aerospace.aero.org> wrote and said that
he checked on dockmaster.NCSC.MIL and found that the Sun
products are not yet on the NCSC's Evaluated Products List 
and do not have an official rating yet.

Jeff Edelheit <edelheit@gateway.mitre.org> wrote and offered 
good information and then was able to get me a copy of Sun's
Product Announcement which I summarise from below.  He also
reports that a "compartmented mode" workstation is under
development with a target of B1 security rating, but is farther
out in development than the ordinary B1-rated SunOS.

Thanks to everyone for quick and helpful responses.

(The below is summarised from Sun's Announcement.)

Sun is developing a version of SunOS called "SunOS MLS" (Multi-level
Security) for the Sun-3, Sun-4, and TEMPEST Suns.  The goal is
to make B1 level security with the product.  They plan for first
customer shipments in June 1989.   Cost will be $3000 for a 2-user
license.  NFS has been enhanced to be more secure and fibre-optic
network cabling is also supported.
-----------[000094][next][prev][last][first]----------------------------------------------------
From:      Hoffman.ElSegundo@xerox.com  30-MAR-1989 23:01:49
To:        SECURITY@pyrite.rutgers.edu
Cc:        Hoffman.ElSegundo@xerox.com
From: Rodney Hoffman <Hoffman.ElSegundo@Xerox.com>

This piece ran in 'Business Week' magazine, March 13, 1989, p. 77:

            TV TECHNOLOGY MAY KEEP CARS SAFER FROM THIEVES
  
   Looking for a better car security system?  Take another look at your TV.
   Using the same technology that sharpens TV images, GTE Corp. scientists 
   have up with a new theft-proof locking system.  The device uses the
   properties of SAW -- surface acoustic waves -- to activate a tiny coil
   embedded in a car key.  As the key turns to open the door or start the
   engine, the coil sends out a coded digital signal needed to unlock or 
   start the car.  GTE makes similar SAW filters to lock in color TV tuners 
   on each channel.

   GTE's auto-lock system, called SAFE for surface acoustic filter encoding, 
   has the advantage of being completely passive:  There are no codes to
   memorize or alarms to disarm.  And unlike other antitheft locks, SAFE 
   needs no electrical contact -- or even teeth on the key.  Eventually, 
   keys for individual drivers could be encoded to automatically adjust 
   the seats and mirrors.  So far, GTE has gotten "a strong response" in
   Detroit, says Scott L. Atkinson, marketing specialist with GTE's Elec-
   tronic Components & Materials Div., who thinks auto makers may offer
   SAFE within two years.  Also eyeing the system, says Atkinson, are 
   foreign carmakers and major U.S. car insurers, who are battling $6 
   billion a year in U.S. car-theft losses.
-----------[000095][next][prev][last][first]----------------------------------------------------
From:      KARYN@nssdca.GSFC.NASA.GOV  30-MAR-1989 23:14:59
To:        security@rutgers.edu, eugene@eos.arc.nasa.gov
I was curious about the Computer Virus Industry Association, too,
and eventually got an address and phone number and got the following 
info.  They charged me 3 or 5 bucks for this info, and they also told
me to send a stamped, self addressed envelope with $1.70 in stamps
on it.  Basically its an 'association' in the loosest sense of the 
word, they are a bunch of consultants who will tell you what you 
always wanted to know about viruses.  To join the association, your 
company sends them a yearly check for $200 and you will be informed 
about viruses.

Seems to me you pay $200 for their consulting services about viruses, 
and since they call you a 'member' they encourage you to tell them all 
you know about viruses, so they can then sell that information to the 
next person.  This association is probably good for people in 
companies where there is no other way of getting the info, but 
for anyone with access to this or any other security list the 
association is probably a waste of money.

(author's note: I just read over what I wrote, and it 
sounds like I am putting this association down, I don't mean it to 
come out like that)

Included in the packet are:

1.  Cover letter describing company history, etc
2.  list of "Companies Providing Anti-Viral Products and Services"
3.  what looks like a copy of a presentation titled, "Computer 
    Viruses: Background, Detection and Recovery"
4.  Another presentation titled, "Anti-Viral Product Classifications"
5.  A short document titled "Anti-Virus Measures" containing common 
    sense information on how to keep your computer secure (e.g. never 
    boot from a floppy drive)
6.  Another presentation titled, "The Six Most Common Computer 
    Viruses".  Contains info on Pakistani brain, scores, israeli, 
    nvir, alameda, and lehigh.
7.  CVIA membership application

For more info about what you get for your five bucks, contact 
KARYN@nssdca.gsfc.nasa.gov
And here's the address of the CVIA:

John D. McAfee, Chairman
CVIA
4423 Cheeney Street
Santa Clara, CA 95054
tele (408) 988-3832
note: If you call the above number they will answer the phone
with 'Interpath Corporation'..the address and phone for the CVIA is the
same as one in the list of companies providing anti-viral products
and services.

END OF DOCUMENT