The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 5 Issue 82

Wednesday 23 December 1987


o NYT article on computers in stock crash
P. T. Withington
o ...BAD PRACTICE to truncate anything without notice
Doug Rudoff
o The spread of viruses and news articles
Allan Pratt
o Common passwords list
Doug Mansur
o Re: IBM Christmas Virus
Skip Montanaro
o Cleaning PC's can be bad for your health...
John McMahon
o PIN verification security
Otto Makela
o Social Insecurity
Roger Pick
o Info on RISKS (comp.risks)

NYT article on computers in stock crash

P. T. Withington <PTW@DIAMOND.S4CC.Symbolics.COM>
Wed, 23 Dec 87 11:51 EST
An article in the Boston Globe yesterday (23 December) covers similar
issues, but raises a few additional points which make me think that (as
usual) the computer is only an unwitting accomplice and not the source
of the trouble at all.

    Date: Mon, 21 Dec 87 21:48:36 EST
    From: (Hal Perkins)
    Promotions [of portfolio insurance] worked: By October, between $70
    billion and $90 billion was invested in funds using some form of the

The Globe article points out that when portfolio insurance was first
"invented" it was dismissed in an article in Fortune (ca. 1980) as a
"carnival act".  Its inventors pursued its promotion however, and the
"invention" of index futures allowed them to make the concept more
palatable to fund managers (since they were no longer required to change
the makeup of their portfolio to participate).  Shortly to follow was
the "invention" of index arbitrage, which provided a ready appetite for
the portfolio insurers' future trading.

My inference is that what legitmized the "carnival act" was not any
understanding of its mechanism, but simply a track record.
Unfortunately there are a large number of investors who believe that
history is an accurate predictor.


    "The problem was that everyone is working from roughly the same
    theories," said Peter U. Vinella, a partner at Berkeley Investment
    Technologies in Berkeley, Calif., which writes many complex trading
    programs.  "They all get the same feedbacks.  And that leads everyone
    to take the same action."

Here is the nub.  My inference is that as long as insurance and
arbitrage were *unusual* investment policies, they actually "worked" by
trading on discrepancies arising from imperfect information.  Of course
their success led to popularity, and eventually to the situation Vinella
describes:  all sellers and no buyers, the downfall of any Ponzi scheme.

    A Fear of Defying the Computer


    "People get lulled into thinking, `My program says this will work,'"
    said Robert H. Mundheim, the dean of the University of Pennsylvania law
    school....  "And you don't have time to think through the assumptions
    that went into the programs -- if you understood them in the first

The Globe points out that the inventors and primary promoters of
portfolio insurance (LOR Corp.) actually did "sanity check" what their
computers told them to do and held off making the massive futures sales
the program directed.  (I believe they realized, if only intuitively,
that their algorithm was operating out of its useful range, because they
had not forseen the discrepancies it was now receiving as inputs.)
However, several of their licensees did exactly as the program directed,
having been lulled into beliving in its infallibility, only to find
there were no buyers.  As the sell orders mounted, depressing the price,
the algorithms, lacking any sanity checks, simply directed more sales.

It's interesting to speculate whether the limited automation of the
exchanges exacerbated the situation or acted as a governor to slow
things down enough for conventional investors to react to the
bargain-basement prices and finally put a floor under the madness.

...BAD PRACTICE to truncate anything without notice (Re: RISKS-5.79)

Doug Rudoff <wiley!doug@uunet.UU.NET>
23 Dec 87 19:12:49 GMT
About two years ago I was working on a project that required coding in PL/I. I
had a problem with running out of memory while exectuting my code. After many
hours of frustration I discovered the problem was that I had two procedures
'put_message' and 'put_page' (which called 'put_message') truncated to the 
same name. This was due to PL/I's truncation scheme of taking the FIRST four
letters and the LAST three of a procedure. Thus, both procedures were
identified as 'put_age' and I ended up running out of memory because of
unintentional recursive procedure calls.

Doug RUDOFF        TRW Inc, Redondo Beach, CA  {cit-vax,trwrb,uunet}!wiley!doug
H: (213) 318-9218  W: (213) 812-2768               wiley!

    [Recursively Call a spade a spade a spade ... but don't expect it to
    return.  (If it weren't Christmas time, and it hadn't been pouring in
    LA, I probably would have refrained from annotating this message from
    RUDOFF THE RED{ONDO} KNOWS RAINGEAR.)  Happy holidays to all.  PGN]

The spread of viruses and news articles (Re: RISKS-5.80)

Allan Pratt <ucbcad!ames.UUCP!atari!apratt@ucbvax.Berkeley.EDU>
Wed, 23 Dec 87 12:01:59 pst
<>The prank seems to be benign, and therefore beneficial.

My contribution was relevant to the above passage: the fact that it was
on the front page of a major metropolitan newspaper (The San Fransisco
Examiner, Sunday 12/20/87) with a more or less in-depth article spread
the implicit warning farther (sociologically) than the virus itself
spread.  (Granted, this metropolitan newspaper serves one of the most
computer-literate parts of the country...)

Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt

    [I think the major point about Trojan horses, viruses, and similar
    problems is that they are relatively easy to perpetrate, but potentially
    devastating on many systems.  The cases we have seen to date are all
    rather benign (except for denials of service) or localized in effect (PC
    graphics ARF-ARF!).  The lesson is that these vulnerabilities exist.
    However, the rather benign cases suggest that deeper concern is 
    warranted.  PGN]

Common passwords list

Wed, 23 Dec 87 11:59 EST
I am interested in making a list of the most common passwords chosen by
users.  I'd like to see if anyone knows of any studies that have been done (I
vaguely recall hearing of at least one such study).  We are writing a program 
to check for poor passwords on our systems.  Please send replies to:
Doug Mansur                   -or-    (
L-308, Lawrence Livermore National Lab., P.O. Box 808, Livermore, CA 94550P

    [At one time "Susan" was reputed to be the most popular American choice.
    I recall a British clipping citing dogs' names as popular passwords.
    However, since many prudent system managers now insist on randomly 
    generated pronounceable passwords, your study might be dated.
    Furthermore, I hope no one is stupid enough to tell you what their
    password is.  But past studies (e.g., Morris and Thompson, UNIX Password
    Security: A Case History, CACM 22 11 November 1979) have encrypted
    initials, dictionaries, etc., with great effect.  If your system permits
    access to unencrypted passwords, your study might focus on that instead.

Re: IBM Christmas Virus (RISKS 5.80)

Skip Montanaro <steinmetz!montnaro@uunet.UU.NET>
Tue, 22 Dec 87 13:33:10 EST
Ross Patterson wrote (in RISKS 5.80):

>(5) Is the Internet similarly vulnerable ?

<>Not to this one.  It plays on several things that the Internet doesn't have:
<>1) A large number of IBM VM/CMS systems.  ...
<>2) A suitable file transfer system.  FTP doesn't apply. ... 
<>3) A good method of determining targets.  The CMS NAMES and NETLOG files ...

The quasi-equivalent of this problem in UNIX systems (and most of the
Internet, because of the large number of UNIX systems it contains) is the
ubiquitous shar file, an ASCII packaging machanism used to transfer code and
other ASCII files via mail and/or Usenet news transfer.  The problem lies in
the way users unpack shar files: they execute them.  Needless to say,
inspection of shar files before execution/extraction is highly recommended.

There's nothing to prevent me from writing a shar file that purports to be a
Christmas card. Execution of it might display the card, check out the contents
of various mail-related files, (like ~/.mailrc and ~/mbox) looking for likely
candidates to send the shar file, then recursively send it.

In fact, the same scheme would work for most operating systems with a
command language that could be executed from a file. UNIX systems are
especially vulnerable, however, because of their large numbers.

Skip (, uunet!steinmetz!sprite!montanaro)

Cleaning PC's can be bad for your health...

John McMahon <fasteddy%sdcdcl.span@VLSI.JPL.NASA.GOV>
Wed, 23 Dec 87 07:40:53 PST
The following "SAFE-ALERT" form was distributed at Goddard Space Flight Center
(NASA - Greenbelt, MD) about cleaning PC's.  The date was 7/29/87, alert number

"Recently an employee of this installation was cleaning his personal computer
screen with a glass cleaner when the screen caught on fire.

The computer had been in use for some time and had built up a static charge.
When the employee went to wipe off the glass cleaner with a tissue, his finger
hit the screen.  This action discharged the static charge causing a spark which
ignited the alcohol in the window cleaner.  A total of 8 personal computers
were checked, with only 1 other catching on fire."

The installation mentioned above was the Naval Weapons Center in China Lake, CA.

The action taken was to inform the employees about what could happen, and ask
them to use a non-flammable cleaner.  If there was a need for a flammable 
cleaner, then employees were advised to discharge the computer before


PIN verification security

Wed, 23 Dec 87 15:53 O
A while back, I posted an article on ATM card security, promising to tell
more as soon as I get the official security guide.  Well, now I have the
guide, and here are some findings, given somewhat verbatim since this
document was distributed as "confidential":
  In Finland, there are two methods of off-line verification of PIN's.
Both are DES-based, so they can be considered pretty secure (unless there
are hidden trapdoors in DES - has the analysis behind its design been made
public yet ?)
  The PIN verification is done by the "verification unit", which consists
of a keypad for PIN entry, the magnetic stripe reader unit and the main
electronics unit, which communicates with the local cash register unit.
The document also specifies which "security modules" may be used in these
verification units: Intel 8751H, Intel 8752H and AMD 9761H.  Can someone
who knows better tell what these units actually are ?  DES-chips ?
  The first method of PIN verification is the same that is used in VISA-
cards internationally: the card number, the PVV-version number (off the
card's magnetic stripe) and the PIN number the customer has entered from
the keypad are all munged through DES, using certain highly secret keys
which are distributed by the banks.  The resulting number is then compared
with the PVV-number from the card's magnetic stripe, and if it is same,
the given PIN was correct.
  The second method used is local to Finland, I guess.  In this, the card
number is encrypted with several highly controlled keys, resulting in the
actual PIN that the client should have given.  There are very strict rules
on key control, for example the master key is divided into three parts and
given to three people who each load their part to the verification unit
ala bank safe keys.
  This document also specifies the encryptation that MUST be used for all
message transmissions to/from the verification unit.  This would seem to
remove problems with faked messages etc.
  The only problem that would seem to arise is key security - if the keys
become widely known, there goes the security.

Generally, it would seem that this type of security is an overkill in
practise.  A local supermart is a good example: they are on-line to the bank
so they can send payment transactions immediately to the bank computer, they
use magnetic stripe readers to read credit card / bank card stripes, but
they still use signatures for verification.  The only reason I can think
for this is that it's simpler for them.  Hooray for minimizing of risks!

A note on ATM's swallowing cards up: my girlfriend lost her card to another
bank's ATM a couple of days ago, since she couldn't remember the new card's
PIN right.  She didn't want them to send the card by mail, since it would
take a few days, so she called the bank the next morning and told them to
keep the card, she'll come and pick it up.  Then she just went there during
her lunch break, showed ID, and they gave her card back to her, since the
card was not "wanted" or anything.  Banks over here seem much more
cooperative then the american ones I've been to.

A safe Christmas, Otto J. Makela, U of Jyvaskyla
Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland   Phone: +358 41 613 847
BBS: +358 41 211 562 (V.22bis/V.22/Bell 212A/V.21)

Social Insecurity

Roger Pick <>
23 Dec 87 11:45:22 EST (Wed)
I have been reading RISKS for a number of months and have noticed that
the contributors seem to take it for granted that social security numbers
cannot be required except in situations involving income.

I would like to know what the basis for this common knowledge is.
Is it a statute?  A court case?  Can you give me a name or a citation
so I can look it up in our local law library?

The reason I am looking for it is that my health insurance plan is demanding
my children's social security numbers.  I seek to keep their social security
numbers private whenever possible in order to reduce the problems they will
encounter if a Big Brother society should come about.  (I give mine out 
without a second thought -- it is already in so many places that I would
have no privacy anyway.)  To be able to cite legal chapter and verse would
significantly strengthen my case; the insurers are presently intransigent.

Roger Alan Pick - QA & Information Systems Department, University of Cincinnati
VOICE:  (513) 475-7166
UUCP: {decuac,psuvax1!gatech!mit-eddie,philabs!phri,pyramid}!uccba!ucqais!rpick
POST:    QAIS - Lindner Hall, Univ. Cincinnati, Cincinnati, Ohio 45221-0130 USA

   [This question is like the Yes Virginia, there is a Santa Claus letter in
   the International Herald Tribune.  Discussion goes back to early RISKS.  PGN

Please report problems with the web pages to the maintainer