The RISKS Digest
Volume 6 Issue 1

Saturday, 3rd January 1987

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

The Christmas Virus
Martin Minow
Password security in multi-user systems
J. Eric Townsend
Re: Program trading
K. Richard Magill
DES and NSA's new codes
Tom Athanasiou
Electronic Interference
Al Watters
American Express security ...
Henry Mensch
SSN / Phone Number / etc. on credit purchases
Jordan Hayes
David Albert
Info on RISKS (comp.risks)

The Christmas Virus [end of the season?]

<minow%thundr.DEC@decwrl.dec.com>
29 Dec 87 09:57
The same comments on the virus from a slightly different (vms) point of view.  
The only new info is the description of the anti-viral software.  Martin
          [Pardon a little initial redundancy.  I did not want to edit.  PGN]

Newsgroups: comp.os.vms
Path: decwrl!ucbvax!QUCDNSUR.BITNET!PYM
Subject: HRISTMA comes but once a year, a virus may be forever.
Posted: 27 Dec 87 22:39:00 GMT
Organization: The ARPA Internet

     By now,  many of you will have heard of the (infamous) CHRISTMA EXEC
"virus" which infected BITNET/EARN/NETNORTH and virtually paralyzed IBM's
internal  network  for a day  or two.   For those who  haven't  seen  the
various postings on the BITNET LINKFAIL list, RISKS-FORUM Digest, etc., I
will summarize  (no flames for the oversimplifications in the interest of
brevity, please).  Originating as a "prank" on a German end-node on EARN,
this EXEC (i.e.  similar to a .COM file - and written in REXX, a DCL-like
language)  displayed,  when executed  on  an IBM  VM system,  a primitive
christmas tree on the terminal and then mailed itself to everyone on that
poor user's NAMES file (i.e.  personal mailing name list) before deleting
itself.   Of  course,  some  users  had network distribution lists  (e.g.
JNET-L,  MEDINF-L,  etc.)  defined  in  their  NAMES  file . . .       [I
personally received six copies of this EXEC from different sources - this
is probably not unusual.]

     While this was a significant problem on  BITNET/EARN/NETNORTH with a
fair number of VM/CMS nodes, the virus clearly could not infect VAXinated
nodes,  of  which  there  are  a  larger  number.   Also,  many  (usually
undergraduate) students on VM/CMS systems are denied network access, thus
limiting  the rate of  spread  of  the virus  beyond an  infected system.
However,  once the virus entered VNET,  IBM's internal  network of VM/CMS
systems,  things really took  off (all VM/CMS systems;   users with large
NAMES  files;   all  with  network access)  and  allegedly brought  their
network to a standstill.

     Initially,  the  problem  required  manual  intervention  by  system
managers to purge CHRISTMA  EXECs  from users'  readers -  but this could
only give a temporary remission in the disease.   Fortunately, a CHRISTMA
eradicator was written (by Eric Thomas, author of the LISTSERV software),
and  also  an ingenious  virus  was developed  (by  Hank ?,  sorry,  I've
forgotten)  to follow and destroy the original  CHRISTMA  virus  and then
self-destruct  in  mid-January.   So now  it's  eradicated like smallpox:
hmmm .  .  .  I expect that there may be another minor epidemic when some
users return from vacation.

     So,  what should we do?  Laugh at IBM?  Say "It can't happen to me."
Look  at  all  those experienced,  computer-wise  IBMers who ran CHRISTMA
EXEC.  Oh yes, there will be flames . . .    platitudes about NEVER using
any software which  you  haven't  written  yourself  -  or is  written by
someone  you  TRUST  ABSOLUTELY  :-) . . .   flames  about  chain letters
and viruses on the network . . .    their authors should be boiled in oil
/ set in RA81 air filter glue / sentenced to do 10 years of RSX SYSGENs /
locked  in  a room  with  only an IBM  PC  /  (substitute  your favourite
nightmare here).  Let's just think a little before flaming.

     Could a "harmless"  CHRISTMA-like virus attack a VAX/VMS system?   A
recent network posting (RISKS?, LINKFAIL?) mentioned the possibility of a
virus  hidden in SHAR files which are _executed_ as .COM  files to unpack
them.   SHAR files  are,  after  all,  an excellent method for _reliable_
software distribution over  gateways.   (This  is  not  meant  to reflect
negatively  on  Michael  Bednarek  in  any  way  -   VMSHAR  is  a  great
contribution and we all have used it or will use it.) But .  .  .  nobody
unpacks one of these distributions with  PRIVs turned on,  do we?   Could
such a virus, like CHRISTMA EXEC, replicate from a non-privileged account
(apart from doing a SET PROC/PRIV=ALL quietly in the middle of the file)?
Certainly,  VMS  Mail won't allow  wildcard SEND (and JNET won't allow  a
wildcard  SEND/FILE),  but,  for example,  a .COM  file could  do  a SHOW
LOGICAL/OUTPUT=CRACKER.TMP,   look  for  logicals  with  syntax  "jnet%",
"BITNET%",  "IN%",  etc.  and try mailing itself to these addresses.  (No
flames about  giving state secrets  to the enemy,  please.   Blind Freddy
could have seen that one.)

     We may not be able to read  a SHAR file in its entirety (looking for
a virus  in  a few thousand blocks  of code),  but I for one am certainly
going to "quarantine" it as far as possible, SEARCHing it for more than a
few key words before unpacking it  from a non-privileged (either  default
or authorized)  account.  Further suggestions from the more devious minds
on the list would be welcome,  please.  Ignorance may be bliss, but it is
definitely NOT SAFE.

     Most if not all  of us have public  domain  software running on  our
systems   -   or  programs  written  by   students   and  our  colleagues
(trustworthy,  of course :-} ).  How many VAX/VMS systems do _not_ use at
least  one piece of  DECUS  software?   This  PD  software,  even if  not
essential,  makes  life easier  and/or  saves hours  of  work.   Software
exchange isn't going to stop now,  nor should it.   We  must be vigilant,
both for our  own  safety,  and as a responsibility to colleagues on  the
network.   We must make  all reasonable efforts to check before executing
software ourselves or posting it to the net -  or making it available for
FTP or putting it  on a BITNET LISTSERV.   CHRISTMA EXEC comes but once a
year, but a virus can be forever.

     Comments from the Info-VAX gurus would be appreciated.  What are the
guidelines for "safe  software exchange"?   What are  the best methods of
checking software for viral  contamination,  granted that we are going to
continue to exchange it?

John Pym

BITNET:  PYM@QUCDNSUR                    Real life:   Dr. John Pym
        (POSTMASTER@QUCDNSUR)                         Department of Surgery
Telephone (613)549-3898 - office                      Queen's University
          (613)548-4879 - home                        Kingston. Ontario
          (613)541-7792 - cellular                    CANADA. K7L 2V6
Chairman, THISLUG (DECUS Thousand Islands LUG)


Password security in multi-user systems

<ucbcad!ames.UUCP!hoptoad!academ!uhnix1!nuchat!splut!flatline!erict@ucbvax.Berkeley.EDU>
Thu, 31 Dec 87 23:13:52 CST
I am the systems administrator at a small software company here in Houston.
(Actually, we're right next door to NASA-JSC and in the McDAC building. 
Anyway...)
McDAC is very, very, very security conscious.  Armed guards and the like.
"Of course", you say, "it is because they deal in the highest of high
technology and in matters of national security."

I work for a small banking software company, Integrated BancSystems,
housed in the same building.  We develop software that deals "only" 
with things like loans, customer accounts, bank customer lists, etc.

Part of our product line is geared towards the latest fad (buzzword?):
LAN's.  PC clone LANS, to boot.

Before we got our LAN for development, we developed on UNIX systems, which
I felt were secure enough for our purposes.  Banks aren't a national security
problem, so they shouldn't require the high standards of security that our
upstairs neighbors have to take.  The LAN's based on IBM PC compatible
computers (Novell SFT II v2.0a in particular) have just blown a huge,
gaping hole in the side of banking security.
I have no particular problem with Novell, and feel that they are
representative of the state of technology in PC compatible based
LAN's.

Point by point:
1.  Passwords are not stored in an encrypted form.  Any person that gains
    the "supervisor" password, or has his "security equivalance" (sic)
    raised to "supervisor"; can go into the "syscon" utility, pick
    "User Information", pick a user's login name, and then pick
    "Password".  Voila'!  The user's password, in ascii, for all to see.
    (A friend claims he has broken the protection scheme that is used to
    write them to the file server's hard-drive, but I have yet to see
    him prove this on my system.)
    [Again, other than this (rather glaring) problem, I think Novell has
      done a rather fine job of making PC clones usable (to some limited
      degree. :-) ) ]

2.  Software products sold to banks are quite often very insecure.
    I feel this is a very important issue that Data Processing managers
    should look into. (Are they still called that in other businesses?)
    An example:
    The SMART software system — an integrated package of "Spreadsheet",
    "Communications manager", "Time manager", "Database manager", and
    "Wordprocessor" — advertises "personal file protection".  There
    are several problems with their implementaion of this idea.
    1.  Only wordprocessor files are actually encrypted with any
        sort of encryption algorithim.
        The spreadsheet files have their password stored within
        the first 256 bytes of text. This pattern can easily be
        discoverd by encrypting a file, then "dump"ing or "debug"ing
        that file and examining what is actually written to the disk...
    --> Or you can just look down a couple of blocks, where the
        raw ascii spreadsheet is stored. <--
    2.  Cursory examination shows that the password used as an
        encryption key is stored in the same way:
        within the first 256 bytes of data, in a simply permutated
        form.
    3.  [This problem is created by the user-unfriendly-ness of
        the SMART system when implemented on a LAN.  (It seems to
        have been originally written for standalone PC, and not
        modified to any great deal for LAN use.)]
        Many system administrators tend to lump all the users in
        "group" instead of "individual" directories, and then
        direct users to "password" their files.
        Reason:
        It is rather involved to set up seperate SMART working
        directories.  Each user must have his own directory of
        screen, printer, and keyboard drivers, along with 3 or 4
        parameter files, a configuration file, and several other
        miscellanious files.  This eats up i-nodes (and their
        equivalent), and takes a while to set up for a new user
        and to remove for an old user.

I feel that these two reasons are more than enough to cause concern
about bank security.
I've only been into computing on a large scale (large = bigger than
a Commodore 64) for only a year or so, and I have been able to easily
defeat the security on programs sold to us.

Disclaimer:  The problems listed above have been reported to the
  management of my company.  They agree that security is a very serious
  issue, one that should be paid a great amount of attention and time.
  Our software uses DES-style encryption in an effort to make up for
  the intrinsic weaknesses in MS-DOS / IBM-PC compatable computer
  security.

J. Eric Townsend ->{uunet!nuchat,academ!uhxnix1}!splut!flatline!erict
713-486-7820, 10am-6pm


Re: Program trading (RISKS-5.79)

K. Richard Magill <umix!oxtrap!rich@uunet.UU.NET>
Mon, 28 Dec 87 15:48:39 est
  [Hugh Miller writes about replacing human judgment with machine 
  judgment with respect to computer trading programs]
>And how will we insure that such enormously complex systems
>will not synergetically go plooey when pushed to their volume or price limits?

We don't.  They are self limiting much in the same way as icy roads
limit speed.  Those who exceed, die.

Even if the minute to minute trading is done using machine judgement,
the day to day, or some long term, will be done by humans, even if it
is just when to turn the machine on and off.  In the near future this
will mean trading strategies change daily and on a per company or per
trader basis.  There would be no incentive to share software as
"winning" depends on doing better than the next guy.

If a company has the resources to "plooey" the market before they suicide,
well, what keeps that company in check now?
                                                         rich.


DES and NSA's new codes

Tom Athanasiou <toma@Sun.COM>
Tue, 29 Dec 87 18:13:01 PST
The other day a posting included the phrase:
    "...DES - has the analysis behind the design been made public yet?"

This reminded me.  I looked into the whole DES controversy in some detail 
about a year and a half ago.  It may be out of date.  Here's a summary:

In 1973, when the NBS called for proposals for a national encryption
system, IBM's LUCIFER system was already in the final stages of development.  
It was good, by all reports so good that it upset the code-breaking side of 
the NSA.  Rather than approving LUCIFER as is, NSA modified it in several 
strange ways to create DES.

LUCIFER's key size was 128 bits; DES had a key size of only 56 bits.  
Thus, it is much more vulnerable to "brute force" attacks.  There are 
2**56 possible DES keys, and as large as this number may seem, it is tens 
of millions of times smaller than the number of possible keys in ciphers
approved for military use.

NSA's weakening of LUCIFER appears to have been deliberate.  According to
David Kahn, author of The Codebreakers, LUCIFER set off a debate within
NSA.  "The code-breaking side wanted to be sure that the code was weak
enough for the NSA to solve it when used by foreign nations and companies,"
he wrote in Foreign Affairs.  "On the other hand, the code-making side
wanted any cipher it was certifying for use by Americans to be truly 
good."  Kahn says that the resulting "bureaucratic compromise" made the key
shorter.  Alan Konheim, former manager of IBM's LUCIFER research project,
recollects, "If they [NSA] had had their way, they would have had 32
bits...I was told at one time that they wanted 40 bits, and at IBM we
agreed that 40 was not enough."

At the same time that the NSA shortened LUCIFER's key, it used classified 
criteria to redesign several numerical tables known as "substitution" or
"S" boxes.  These S boxes control permutations that are key to the DES 
algorithm, and NSA's critics have long suspected that the changes to them 
might make the system vulnerable to a "cryptoanalytic" attack.  In other 
words, the boxes might conceal a trap door.  

Despite repeated rumors, such a trap door has never been found.  However,
mathematicians have unearthed several peculiar properties in the S boxes,
properties that were not present in IBM's original design.  They have also
demonstrated the possibility of weakening the cipher by introducing hidden 
regularities into the S-boxes.  Still, no one has managed to use these 
discoveries to mount a successful cryptoanalytic attack on DES.  

The controversy over DES eventually subsided, but in late 1985 NSA suddenly, 
and gracelessly, abandoned the cipher.  Directly contradicting years of 
reassurances, Walter Dealy, then NSA's deputy director for communications 
security, told Science that he "wouldn't bet a plugged nickel on the Soviet 
Union not breaking [DES]".  People in the industry felt betrayed.  According 
to Herb Bright of Computation Planning Associates, quite an uproar ensued in 
the normally quiet halls of the American National Standards Institute when 
NSA announced new ciphers to replace DES.  

These ciphers are designed to be distributed as pre-sealed and tamper-
resistant integrated circuits.  The encryption algorithm hidden within the
chips is classified.  It remains unknown even to engineers who work with 
the chips.  Critics feel that such secrecy offers NSA the chance to build 
a real trap door into the chips.  Herb Bright: "With a hardware black box
you can describe several schemes that would be almost impossible to test 
for from the outside and could, in effect, constitute a hardware Trojan 
Horse".

My conclusion?  That NSA probably hadn't put a trap door into DES, but felt
that, what with all the heat it was taking anyways, that it might as well 
replace DES with a cipher that really did contain a trap door.  The new
cipher chips may indeed contain such a trap door, but so little is known 
about their internals that speculation has been uninteresting.

Further, it is impossible — in principle — for the agency to exonerate itself
from charges such as these as long as it promotes ciphers based on secrecy
rather than algorithmic inpenetrability.  Such ciphers do, I believe, exist
(I'm no expert) but that's another story.
                                                  — Tom Athanasiou


Electronic Interference

<SAC.96BMW-SE@E.ISI.EDU>
29 Dec 1987 22:28-CST
  The following is extracted from Aviation Week and Space Technology, 
Dec 7, 1987, Vol 127, No. 23.

    "Air Force Examines Effects of Microwaves on Electronic Systems" U.s. Air
  Force Gypsy microwave device is being used to check the susceptibility of
  electronic systems to currents induced by high-power microwaves, and to
  investigate methods of increasing device efficiency.  The Air Force's
  Forecast 2 report listed high-power microwaves as a promising weapon and
  there has been interest in the subject dating back over 30 years.  Gypsy and
  other microwave devices are being managed by the Air Force Weapons Laboratory
  at Kirtland AFB, N.M., where more than 600 scientists and engineers held a
  secret conference on high-power microwave technology last December (AW&ST,
  3 Nov 1986, p. 151).  Soviet physics publications also have shown an interest
  in such devices.  Gypsy can produce more than one gigawatt of power in short
  pulses at several percent efficiency and can be tuned over 0.8 - 40 GHZ. 
  Gypsy uses the virtual cathode oscilator (VIRCATOR) principle, under which an
  electron beam penetrates an anode mesh with a current density greater than
  the space charge limiting value.  The high negative charge beyond the anode
  represents a virtual cathode, in which the electrons bunch in phase and
  oscillate at stable frequencies.  "
                                           Al Watters


American Express security ...

Henry Mensch <henry@garp.mit.edu>
Sun, 27 Dec 87 21:44:26 EST
I am a bit skeptical of American Express' verification methods, also.
Recently I decided that my AmEx plate was in sorry shape and I phoned
their toll-free customer service number to arrange for a new one.
After I made my request clear, I was transferred to another CSR who
asked me two questions (what SS# I put on my application, and
something else that I don't recall offhand now).  After I answered the
questions, I  was told that my replacement (new) card would arrive in
ten days (it arrived in three days).  

Does this mean that anyone who knows a bit about me can get my AmEx
plate, too?  Scary ...

# Henry Mensch / <henry@garp.mit.edu> / E40-379 MIT, Cambridge, MA
#      {ames,cca,rochester,harvard,mit-eddie}!garp!henry

    [Coincidentally, Steve Anthony <Anthony@ALDERAAN.SCRC.Symbolics.COM>
    asked Why are Mother's Maiden Names Required?  PGN]


SSN / Phone Number / etc. on credit purchases

Jordan Hayes <jordan@ads.arpa>
Tue, 29 Dec 87 18:16:37 PST
Almost everyone who has talked about the question of "Why do stores want my
phone number on the charge slip?" have clearly never worked in retail sales
before ... something *always* goes wrong, and a phone number is a quick way for
the store to contact you.  Sure, MasterCard doesn't require it, but remember
we're talking about (often) fast transactions by people who are paid very
little to make sure details are correct.  I have been called at least a half a
dozen times to correct mistakes on those little charge slips.  It has saved me
lots of time later when I would have had to correct the mistake with the VISA
or MasterCard company when my memory of the incident and my receipts were long
gone.  I wish they didn't put my number on the same piece of paper as my
account number, but i'm glad they were able to get a hold of me.  
                                                                      /jordan
    [Also commented on by James M. Boyle, and by Christopher Garrigues 
    <7thSon@SPAR.SLB.COM> who quoted at length <!> from /Why Do Clocks 
    Run Clockwise?/ by David Feldman, Harper & Row, 1987, and discussed 
    the return of forgotten cards...  PLEASE BE BRIEF, GUYS...  PGN]


SSN Required Disclosures

David Albert <albert@harvard.harvard.edu>
Fri, 25 Dec 87 12:09:40 EST
>Organizations try circuitous ways to get the SSN.  For example, when one
>gets or renews a driver license in California, he finds a place for
>inserting the SSN but without explanation....

I just had my passport renewed.  On the renewal form, was a space for SSNs,
with the word "optional" in parentheses under the slot — but the word had
been crossed out in pen.  I asked the (post office) clerk why, and he told
me that giving my SSN was no longer optional.  I assume that most people stop
asking questions after such a response, but I went on.  I asked if the SSN
was essential to receiving my passport, and the clerk said no!  He said that
if I did not put my SSN on the form, I would still get my passport, but that
the IRS would charge me a $5 penalty on my income tax returns.

Was the clerk making all of this up?  The whole thing sounds very strange.
Or does any or all of his story have a basis in fact?  I decided not to put
my SSN on the form, although if I was in a hurry to get the passport and
worried about delays, I might have included it to be sure the passport arrived.
The passport arrived about two-three weeks later, as expected, with no delays
and no warning about any future penalties.  Does anyone have an explanation?

David Albert                 UUCP: ...{ihnp4!think, seismo}!harvard!albert    

Please report problems with the web pages to the maintainer

x
Top