The RISKS Digest
Volume 6 Issue 61

Thursday, 14th April 1988

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

Obscure C contest gaffe
Matthew P Wiener
Risks of Lap-Tops in Exams
PGN
Re: Macintosh Power switch
Greeny
Crimes of the Depressed
Vin McLellan
More evidence for an old risk — Enigma
Dave Mankins
Norwegian embezzlement
Eirik Kim Pedersen via David Edwards
Race, identification, and muddly thinking
David Thomasson
"Race" as ID
Will Martin
Re: File "RISKS-6.FEYNMAN" — and a ghost story
Jerry Leichter
Info on RISKS (comp.risks)

Obscure C contest gaffe

Matthew P Wiener <weemba%garnet.Berkeley.EDU@violet.berkeley.edu>
Sun, 20 Mar 88 20:16:47 pst
The obscure C contest, whose past winners were recently distributed on
comp.sources.unix, had a curious gaffe.  The programs were named after the
winners, and the Makefiles produced similarly named binaries.  The user's
mindset is to puzzle with the programs to figure out what they're doing.
The documentation is deliberately cryptic, and all unusual behavior is
considered par for the course.

So guess what happens when Larry Wall is a winner?

I tried out "wall" as indicated, and got all my input echoed back
in a broadcast message, and error messages about various ttys being
unwriteable.  Hmm, thinks I, what's Larry up to this time?  I try
some more input, and get this same stupid echo and error messages.
Hmm, thinks I, maybe running it in Emacs isn't a good idea.  Etc.

So I ended up annoying a dozen people for a minute before I noticed
the discrepancy between the documentation's references to "lwall" and
the Makefile's references to "wall".  Oops, thinks I.  "wall" is the
standard UNIX facility for writing a message to all users.

For an amusing variant of this, consider the possible reactions among
some users were his name Larry Rogue.  ("Gosh, 1000 bytes and it plays
a full game of rogue!  How does he doooo that?")

And while I'm at it, let me predict that within a year or two, a
fiendishly obscure virus is going to be among the winners.

ucbvax!garnet!weemba    Matthew P Wiener/Brahms Gang/Berkeley CA 94720


Risks of Lap-Tops in Exams

<neumann@csl.sri.com>
Thu, 14 Apr 88 08:51:24 -0800
Harvard Business School faculty member Mark Albion has confirmed that
students can take their finals on blue books or they can use lap-top
computers.  There are potential problems with taking an exam using a lap-top
computer.  Some of the exams last up to four hours, presenting the risk that
a computer's batteries will die during the test.  And Albion said that on at
least one occasion, a computer glitch erased a student's whole exam.
[From Bob Greene's column in the San Francisco Chronicle, 13 April 1988]

A usually reliable source suspects that the students get blank disks from the
professor, so they can't be tempted to bring in a disk with lot of information
on it! But what about storing your course notes?  What about modems linking
students to one another for interactive collusions?  What about Trojan horsing
the competition?  What about planting a Trojan horse on the diskette so that
when the professor tries to load it, HIS memory is contaminated — e.g., with
a program to change the grade database?  The fertile minds of students can
undoubtably come up with other exciting scenarios.


Re: Macintosh Power switch

GREENY <MISS026%ECNCDC.BITNET@CORNELLC.CCS.CORNELL.EDU>
Wed 13 Apr 1988 21:22 CDT
>...Ive heard that the macintosh power switch really doesnt turn off the power

This is correct but only with respect to the MAC ii and the Lisa....
on both of these machines, when one turns off the power, the machine transfers
control to a SHUTDOWN MANAGER which then takes care of powering down the
hard drives, and what not....to turn on the machine one simply presses the
power switch again.  *OR* in the case of the Mac II one can simply select
SHUTDOWN from the Special menu and the machine will shutoff on its own --
to reactivate the machine, one hits the RESET key on the keyboard.

When shutdown is selected on an SE or a Plus or whatnot, the SHUTDOWN
MANAGER simply displays a message saying (basically) "its ok to shut
off your mac now..." and does nothing else....you have to take care of
powering down your hard drive, etc...

hope this helps....for more info on this see Inside Macintosh vol. V (I
think....) available from Addison-Wesley
                                                  Greeny

Bitnet:MISS026@ECNCDC
Disclaimer: If it's really me on this account, then I might be responsible,
            but if it's not, then who can you blame?


Crimes of the Depressed

"Vin McLellan" <SIDNEY.G.VIN%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Thu 14 Apr 88 04:43:46-EDT
   The April 18th issue of Business Week had an interesting aside in a major
story on "Stress: The Test Americans Are Failing," a general round up on the
impact of layoffs, mergers, and technological changes, particularly in
middle management. With automation already undermining job security,
particularly among middle managers, post-Crash budget cuts have led to to
widespread layoffs among white collar professionals. All of this
excacerbates the long-term trend of middle managers coming to the conclusion
that their corporate "parent" is quite willing to betray them, to sacrifice
them as a budgetary footnote, and thus doesn't deserve loyalty... perhaps
not even honesty.

   The Wall Street culture displays new and growing problems in alcohol use,
fear, anxiety, and poor morale among employees and executives. Reports the
Business Week research team: "Often employees who lose their jobs react with
furious anger. 'In the extreme, they shoot somebody,' says (grad school prof
Robert Dewar.) Acts of sabotage, particularly of records and computer
data,are common. Human resource executives at half a dozen big companies
privately admit to destructive outbursts by laid-off managers."

  Donn Parker of SRI used to talk a lot about corporations never realizing
how much trust they had invested in employees with EDP access, authority,
and responsiblity. It sounds like some, just because they've acted with the
callous capitalism we expect of MBA-trained managers, are learning the hard
way. These corporate rebellions seem to be seldom reported — except when a
broker shoots his former boss, as happened last week here in Boston — but
there is an sad saga of RISKS unfolding out there. Where does it impact
security budgets? Perhaps in demand for post-password access systems, tokens
and biometrics. What executive (what employee for that matter) can't learn a
few other employees' passwords in any given week?

Vin Mclellan, The Privacy Guild, Boston, MA               (617) 426-2487


More evidence for an old risk — Enigma

Dave Mankins <dm@diamond.bbn.com>
Thu, 14 Apr 88 10:31:04 EST
Alfred Hodges biography of Alan Turing, ``Alan Turing: The Enigma'', relates
the story of deciphering the Enigma encryption system.  The key to the
decipherment was making a clever guess as to the plaintext (successful guesses
were known as `cribs') for a single word in a message, and then matching the
message against that word in hopes of finding the proper setting for the
rotors of the Enigma, which would allow you to decrypt the whole message.

While this might seem like a hopeless task, military messages have a
stereotyped form and a limited vocabulary (words like ``attack'' and
``General'' keep cropping up), making the task much easier.  Hodges says (p.
184):

    Nor was it a trivial matter to guess the probable word, nor to
    match it against the cipher-text.  A good cipher clerk, indeed, 
    could make these operations impossible.  The right way to use
    the Enigma, like any ciphering machine, was to guard against
    the probable word attack by such obvious devices as prefacing
    the message with a variable amount of random nonsense, inserting
    X's in long words, using a `burying procedure' for stereotyped or
    repetitious parts of the transmission, and generally making
    the system as unpredictable, as un-mechanical, as was possible
    without the loss of comprehensibility to the legitimate receiver.
    If this were done thoroughly the accurate `cribs' required for
    the Bombe [the cryptanalytic device designed principally by
    Turing for attacking the Enigma code] could never be found.
    But perhaps it was too easy for the Enigma user to imagine
    that the clever machine would take care of itself, and there
    were often regularities for the British cryptanalysts to
    exploit.

Cracking the Enigma naval code made it possible for convoys to avoid
U-boats, and made it possible for the British Navy to locate and destroy
U-boats.  The sudden change in the tonnage sunk by the U-boat offensive once
the naval Enigma was cracked led to an investigation by the Germans.  Says
Hodges (p. 201):

    In fact, the operation _had_ betrayed Alan's success, for the German
    authorities decided that the positions of the supply vessels had
    somehow been disclosed, and set up an investigation.  Their experts,
    however, ruled out the possibility that the Enigma cipher had been
    broken.  Instead, they pinned the blame upon the British secret
    service, which enjoyed a high reputation in German ruling circles.
    It was a diagnosis remote from the truth.  [Hodges elsewhere says
    the British military, told the Enigma decryptions came from the
    Secret Service, ignored them for the most part, since the Secret
    Service had a reputation for being wrong 80% of the time.]  They 
    had assigned an _a priori_ probability of zero to Enigma decryption,
    and no weight of evidence sufficed to increase it...

    The Bombe method, which was central to the system, hung upon a single 
    thread.  If, to be on the safe side, the Germans had gone over to a
    double encipherment of _every_ message, then there would have been
    no more cribs, and all would have been lost.  At any time, the mere
    suspicion that something had gone wrong might stimulate such a 
    change...

It's an old moral: your security may be foolproof, but the people trying
to subvert it might not be fools.


Norwegian embezzlement

<NMIEP%NOBERGEN.BITNET@CUNYVM.CUNY.EDU>
Mon, 21 Mar 88 19:42:06 EMT
Maybe the latest incident on computer embezzlement? Two employees of the
largest Norwegian clearing house, Bankenes Betalingsentral BBS, are charged
with attempted fraud.

The scheme was apparently in accordance to the old dream of redirecting
transactions to other accounts. The particular day of the attempt, there were
to be a large number of social security benefit transfers. The possible
outcome is said to be app. ! 250 million. One of the two had an operator
type job, with access to tapes. However, the whole thing was set up in
such a way that it was easilly detected by regular security checks.

This hopefully shows that security does work, and that the notion that
no cases have ever been spotted due to security routines, is not true.

Eirik Kim Pedersen


Race, identification, and muddly thinking

David Thomasson <ST401405%BROWNVM.BITNET@MITVMA.MIT.EDU>
Thu, 14 Apr 88 15:49:40 EDT
Les Earnest writes in reply to my earlier note:

>Thomasson apparently believes that everyone belongs to some race
>and that that race is determinable. He probably also believes
>that all dogs belong to some breed. I would like to accompany
>him to a city pound somewhere and listen to him identify all the
>mutts there.

"Apparently believes...probably believes" — more Straw Men. In fact, I
believe that virtually everyone can be put into some racial category that is
very useful for purposes of identification, even though such categories are
not biologically precise. As for the rest of the above, Earnest's argument has
gone to the dogs.

>The things that Mr. Thomasson lists [hair color, eye color] at
>the end are useful identification properties. "Race" is not,
>unless you are a racist.

Granted the biological imprecision of racial categories, one must consider
their usefulness in identifying people. In three years with a police
department, I never knew of a case in which this imprecision worked against
the purpose of identification.  I knew of hundredes of cases in which racial
classification helped greatly. This is a matter of plain fact, and to suggest
that one is a racist for pointing it out is absurd. By the way, the term
"racist" is only as clear as one's definition of "race" — something that
Earnest says is signally unclear. Once again, confusion runs rife in RISKS.

>Color of skin and color of hair _are_ useful for identification
>and may reasonably be included on a drivers license.

I agree. In my experience, "race" has been roughly equivalent to "color of
skin" in police work. So, while it's true that "race" is biologically
imprecise (even incorrect), those who use race for identification purposes
aren't concerned about biology — no more so than when they use "build" --
stocky, thin, average, etc. Should we brand the latter as "buildists"?


"Race" as ID

Will Martin — AMXAL-RI <wmartin@ALMSA-1.ARPA>
Thu, 14 Apr 88 15:41:07 CST
Inspired by the follow-on discussion of "race" as a valid datum for driver's
licesnses and suchlike documents: Obviously, since "race" is such an 
undefinable term, and an individual's "race" cannot be accurately determined
by merely looking at them, the ID factor should be changed to "skin color".

How would one know what to put in a "skin color" block on a form? Well,
you would have a chart, with various colors on it, like a paint-chip 
match-up chart or the kind of things medical technicians use to match 
the colors in a test tube when they are mixing reagents with specimens.
Each chart-entry color block would have a number, and you'd put that
number on the form.

But, you ask, where on my skin would I match this chart? Well, that IS a
problem — a fair-skinned person's skin color can vary from pale white
in the winter to fiery red or reasonably tan in the summer or after
exposure to UV light, and this is likely to be apparent on parts of the
body exposed to the sun — face, hands, arms, maybe even legs or torso.
Darker-skinned people also have variations in their skin color, though
the range may be less dramatic.

Therefore, the "official" area of comparison will have to be some part of the
body normally NOT exposed to sunlight. Where will that be? Well, I guess, for
reasons of decency, the only part allowable will be the buttocks. Normally
covered, yet readily exposable for comparison purposes. Therefore, after this
procedure is implemented, the normal citizen's response on being approached by
a policeman or other official who will need to identify them will be to turn
their backs, pull down their pants, and bend over, presenting the skin on their
buttocks for an official comparison....

:-) Adds new dimension to the old "Assume the position!" command, eh? :-)
Will Martin  


LEICHTER-JERRY@CS.YALE.EDU <"Jerry Leichter>
Thu, 14 Apr 88 17:16 EST
 <LEICHTER@Venus.YCC.Yale.Edu>
Subject: Re: File "RISKS-6.FEYNMAN" and a ghost story 

    [Sorry about the FTP difficulty.
    Jerry and I had a dialogue on an FTP problem that seems to permit
    get stripe:<risks>risks-6.feynman ... TO WORK, BUT NOT  
    cd stripe:<risks> FOLLOWED BY get risks-6.feynman ...     Beats me.
    Also, some systems are CASE SENSITIVE, and add further confusion.  PGN]

Reminds me of a great "ghost story" from the days when we had a pair of 20's
here.  A bad block in just the wrong spot on the disk - in the directory
structures, I guess - could lead to a crash whenever it got touched.  Such
a bad block appeared in a bulletin board; every time a message got posted
to the bulletin board, the system would crash.

The kicker:  It was the CRASHES bulletin board, where information about system
crashes was posted.
                            — Jerry

Please report problems with the web pages to the maintainer

x
Top