The RISKS Digest
Volume 12 Issue 29

Tuesday, 10th September 1991

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…


CIA dumps on the National Security Archive
Tom Slone
CAA grant Cat IIIB autoland clearance for 747/767
Martyn Thomas
Follow-up on Hobson's M16 story
Jim Purtilo
Risks of Incompatibilities
Harry Erwin
Crackers for hire
Mark Seecof
Re: Salomon Brothers — Database Design
Dan Drake
Re: Risk assessment: a specific experience
Peter Wayner
Re: The risk of thinking we are in control
Larry Seiler
Re: National characters on car plates
Torsten Lif
Re: Failsafe mode for 3.5" Floppies
Re: Number of virus events dropping
Mark Hittinger
Re: Prize for Most Useful Computer Virus
Raymond Chen
Richard A. Schumacher
Dave Butterfield
It is RISKy to believe that Averages are `average' [!]
David Paschall-Zimbel
Seventh Annual Conference on Computer Assurance
James Bret Michael
Info on RISKS (comp.risks)

CIA dumps on the National Security Archive

Tom Slone <>
Mon, 9 Sep 91 18:43:50 PDT
The National Security Archive (NSA), a non-profit clearinghouse for Freedom of
Information Act (FOIA) materials, requested from the Central Intelligence
Agency (CIA) a list of materials that the CIA had released under the FOIA.  The
CIA responded to the request by producing "a random dump", 5000-pages long
summarizing the released material.  The NSA and the CIA are frequently at odds
with each other, hence the "hostile" reply by the CIA.  Under the FOIA,
agencies are not required to create (i.e.  organize, sort, or merge) data,
merely to provide information that already exists.  So, it is unlikely that the
NSA would have any recourse other than to attempt to reconstruct the index from
the info-garbage it was given. [Common Cause 17(4): 20 (1991)]

CAA grant Cat IIIB autoland clearance for 747/767

Martyn Thomas <>
Tue, 10 Sep 91 12:02:06 BST
Flight International (11 Sept 1991) reports that British Airways has been
granted Category IIIB autoland clearance for its 747-400s and 767s by the UK

Cat IIIB means that autolandings are permitted where the decision height is
touchdown (zero altitude cloud ceilings) and the forward visibility is zero.
BA are requiring 100 metres visibility for the 747 to taxi (75m for the 767).

The clearance was granted after the CAA has monitored "almost flawless"
autoland trials. 440 approaches were demonstrated on the 747, 520 on the 767.

"At the heart of the system in both types is the Collins FCC132 flight control

The 747 clearance includes 3-engine operation. The single-engine limits for the
767 are 14m decision height and 200m visibility.

BA expects FAA clearance for Cat IIIB in about six months.

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:    +44-225-444700.   Email:

follow-up on Hobson's M16 story (RISKS-12.28)

Jim Purtilo <purtilo@cs.UMD.EDU>
Mon, 9 Sep 91 18:58:27 -0400
John Hobson gives a nice summary of the risks associated with rushing a weapons
system into use either prematurely or after lots of modifications are mandated
by paper-pushers.  He makes passing reference to the greater-than-usual need
for cleaning of the firearm in its second major ...  umm ...  "distribution"
(the M16A1).  The detailed story behind that is itself a study in mismatched

The cartridge ultimately chosen for the M16 was originally a ``wildcat'' round,
and to some extent it evolved with the light rifle designs (some of which are
referred to as the Stoner system, although Eugene Stoner's ideas affected to
several products of the era ...  the designs were successively owned by several
companies during early 60's.)  One of the goals for this combination of rifle
and cartridge --- as inspired by those nice folks at DARPA, I believe --- was
to have a system that we average users would not have to waste time cleaning at

The system as rapidly tested and then fielded achieved this goal.  Then
government procurement got into the act.  When the contracts for large
quantities of ammunition were written, the part of the specification about not
needing to clean the rifle was violated: to serve manufacturing needs,
companies used a slightly different formula for the powder than was used in the
original cartridge.  Its use resulted in much greater accumulation of residue
in the rifle's gas system, in turn increasing failure rates (often with
consequences that didn't have as happy an ending as Hobson's story).  The whole
mess was made worse since everyone was told *not* to clean the rifle, and no
cleaning kits were shipped with the first rifles delivered.  Before the problem
was sorted out, congress got involved and the reputation of an otherwise
serviceable system was permanently damaged.

For what it's worth, those of us who actively compete in this class of shooting
sports use the M14, which led off Hobson's article.  I guess we either view the
committee-designed tweaks to the Garand design as "features" or we have longer
arms than he does.

Risks of Incompatibilities

Harry Erwin <trwacs!>
9 Sep 91 12:30:01 GMT
I'm interested in identified incompatibilities between the various US
Government standards, beginning with

  B2 Security

in various applications.  I know of one between UNIX-based POSIX
implementations and Ada tasking that makes the combination inappropriate in
safety-critical real-time and near-real-time applications, and I'm interested
in identifying any others that are known for specific applications.


There is a real issue. Ada running over UNIX can't handle data enablements of
tasks reliably--the problem being that you don't have access to a test-and-set
instruction and you can be interrupted in the middle by the arrival of data
from outside.  The result is spurious enablements and the loss of other
enablements.  That can be disastrous in a safety- or nuclear- critical system.
How many nuclear-capable systems have been written using Ada tasking over UNIX?
How many other problems have been created by incompatible standards? If you
want a background brief, call me at (W)703.734.6092 or (H)703.758.9660.

Harry Erwin   Internet:

Crackers for hire

Mark Seecof <>
Tue, 10 Sep 91 10:50:05 -0700
In the September 19th Rolling Stone at page 67 an article titled "Samurai
Hackers" by Lynda Edwards tells us that a: "new breed of hacker has been
finding a niche in the corporate world in the last two years.  These hackers
are hired by white-collar professionals at ad agencies, law firms, newspapers,
and investment houses who want to steal co-workers' ideas and clients or
pillage supervisors computer files for marketing strategies, performance
evaluations and managerial gossip."

Ms. Edwards presents several tales of crackers hired by unethical people in
business to snoop in or sabotage other peoples' computer files.  She also
describes how victims sometimes hire their own crackers to mount a
counter-attack.  The crackers use their knowledge and skills to ferret out
information from companies' networks and minicomputers.  They usually receive a
leg up from their employers, who get them modem 'phone numbers and basic
account/password info.  The crackers then overcome or bypass the often trivial
security on the target systems.  Most of what they do could be done by any
jackleg expert with a given system, but the crackers are the agents of computer
illiterates and thus constitute a threat unconsidered by the managers of
systems in non-computer businesses.

These crackers are seen to be somewhat akin to the wandering samurai of Japan's
past.  They work as mercenaries, honing their own skills and testing them in
combat on behalf of employers they often hold in contempt.  (The crackers are
said to refer to ignorant computer users as "Stupids.")  The samurai image is
distorted and romanticized but the jobs the crackers take on are very real.

These crackers are well paid by those who hire them through bulletin boards or
by word-of-mouth.  Tales of their exploits circulate on BBS's and they are
getting some notice in 2600 magazine.

   [Begin Mark S.'s comments.]  Of course, the notion of the computer whiz
employed by some nefarious scheming man or woman of business is not new.  What
is new is the increasing dependence of service businesses on networked PC's.
In the past non-computer firms tended to rely on computers and software
dedicated to certain business tasks like accounting, process control,
engineering, printing paychecks.  These were often vulnerable to cracking for
one purpose or another, but they weren't much of a resource for "fuzzy"
information like supervisors' memos or private e-mail.  Even offices using
word- processing systems often relied on stand-alone machines which were easy to
crack if you had the office key but impossible to crack by 'phone or from
another office because they were not connected to any communication links.
Only recently have PC networks become all-purpose communication tools in places
like law or advertising offices where you can find memos, workups, payroll
info, private diaries, electronic mail, etc. all lurking in the system.

   All in all, this sort of thing seems to bolster the argument that systems
should be designed with security features even if the end customer doesn't know
to ask for them.  A cracker given access to one employee's account should not
be able to use that access as a springboard to crack all of the other accounts
or data on the system.

Mark Seecof <>  Publishing Systems Dept.  Los Angeles Times

Re: Salomon Brothers — Database Design (Dye, RISKS-12.28)

Dan Drake <autodesk!gilroy!>
Tue, 10 Sep 91 09:43:39 PDT
>Bravo.  The database programmers made a mistake.  The Salomon traders
>committed a crime.

Not quite.  The programmers implemented a design that was laid down in detail
(you may assume, and hope) by analysts working under the direct orders of
executives from Operations and Finance.  It's the job of those gentlemen to
ensure controls and audit trails.  Their failure to do so is much more serious
than an error by programmers: it is more evidence of incompetence and/or
corruption, most likely both, pervading the company.
                                                    Dan Drake

Re: Risk assessment: a specific experience.

Peter Wayner <>
Tue, 10 Sep 1991 13:37:05 GMT
Mark Fulk's article on the fetal tests on pregnant women brought back memories
of my younger days several years ago when I was in Yale Med School. Well, it
was only for a day and I was visiting friends and they took me to one class
which was on pre-natal diagnosis.

I remember a very practical and straight-forward professor discussing all of
the possible techniques for checking out the womb and making sure everything
was okay. He would carefully explain the technique and all the facts you could
discern from the various bits of bio-matter you could snag from the womb. The
Maternal Serum Alfa-fetoprotein test is only the beginning of their bag of
tricks. It turns out that the doctors can't learn too much from this one
because the fluid comes from the mother and contains only a very dilute amount
of the child's bio-matter. The next step up was to get some of the chorion
(sp?)  which is essentially the boundary layer between the placenta and the
uterus. All the nutrients pass through this membrane so it is rich in data. The
most aggressive procedure, though, was when they poked around with a needle
until they managed to find the placenta. Then they grabbed a bit of fetal
blood. This, the professor explained, was a data gold mine.

The rub was inserted very parenthetically at the end of each section of the
lecture. He would say things like, "the amniocentesis test is the most successful
and we find we only induce miscarriages in 1 to 2% of the time." (All numbers
in this section are subject to bad memory fudging.  They are approximate.) I
remember thinking to myself, "Wow! 99% that's great!" because I think I was
lead on by the can-do tenor of the lecture.

About 5 minutes later I realized that "inducing miscarriages" was not the same
as failing to cure cancer or a cold. It was a big deal.  Statistically it was a
violation of the Hippocratic oath. The patient died because the doctor was
curious. And as it was the only "cure" they have for Down's Syndrome or other
tri-somic babies is abortion.  The tone of the lecture, though, was much worse
that the attitude that you couldn't make an omelette without breaking eggs.
They didn't do any of the risk analysis or any number crunching what-so-ever.
The lecturer just ploughed on and his manner and diction was just saying,
"We're doctors. This is what we do."

Peter Wayner   Department of Computer Science Cornell Univ. Ithaca, NY 14850    Office: 607-255-9202 or 255-1008

Re: The risk of thinking we are in control (Kerns, RISKS-12.24)

Tue, 10 Sep 91 12:35:50 PDT
Robert W. Kerns lists this point that makes people dislike certain risks:

  *  Low amount of individual control over individual risk factors.

This is a very important point but not quite accurate.  It is *perceived*
control or *perceived* lack of control that affects risk aversion, and it
is the difference between perception and reality that injects a lot of the
irrationality into most people's risk avoidance behavior (myself included).

For a simple example, one of the effects of being drunk is thinking that
one isn't — hence many people at great risk of injuring themselves and
others go ahead and drive anyway, because feel that they are in control.
I think people's apparent preference for old familiar risks over new risks
is in the same category — familiarity breeding a false sense of control.

But preferring risks where one has individual control is, indeed, rational,
provided that one really has control, and doesn't just feel one has control.


Re: National characters on car plates

Tue, 10 Sep 91 11:10:08 +0200
As has been said before, the Scandinavian alphabets contain letters "alien" to
Anglophones. One such is often referred to in English as "A-ring". In Danish it
is written "aa". You can get it on a SUN keyboard by hitting "<compose>A*". It
has ISO8859-1 codes 0xc5 (upper case) and 0xe5 (lower). On a PC it has
character codes 0x81 and 0x8c.

Vehicles from the Finnish archipelago A*land all have numbers starting with
"A*L", followed by some digits. Since they are part of Finland, they may use
the "SF" identification marker when travelling abroad, but some prefer to
underline their regional identity by using an "A*L" sticker. I wonder how
French police computers are set up to handle all this. The possible
permutations of confusing mistakes here are fascinating.

Torsten Lif,  Ericsson Telecom AB, EO/ETX/TX/ZD,  S-126 25  STOCKHOLM, SWEDEN
Phone: +46 8 719 4881

Re: RISKS of floppette write-protect systems (Phillips, RISKS-12.28)

Bart Massey <>
Mon, 9 Sep 91 16:53:26 PDT
> ... In the days of the 5 1/4" diskettes, the sensing was in the opposite way

Worse than that, *both* senses of write protect existed!  If I recall
correctly, the 5.25" floppies sold by a certain major retail electronics outlet
differed from those sold by a certain major mainframe and microcomputer
manufacturer in this respect!  I was working with both kinds of equipment at
the time (sigh) and, if I remember right, trashed a diskette by getting
confused by this at one point.

> ... it seems to me that the position of the plastic tab in the open
> position signifying "protected" is backwards from a fail-safe
> point of view.  If dust prohibits sensing the position, or the
> detector/light source fails, the drive will incorrectly assume
> that the disk should be writable.

Ahh, but the chief failure mechanism for the 5.25" diskette write-protect
system was for the little "sticker" which was commonly used to write
protect/enable the diskette to fall off — this failure should make the disk
write-protected, no? :-)

Probably the 3.5" diskette emulates the argument of the above paragraph, even
though it is no longer valid.  What it *should* do, IMHO, is have the whole
slider open, and use 2 LED/sensor pairs to write-enable the disk, with the
obvious state table.  Of course this would add $5 or more to the disk drive
cost, for a possibly rare failure mode...
                                             Bart Massey

Re: Failsafe mode for 3.5" Floppies

Mon, 9 Sep 1991 19:19:46 PDT
5.25" floppies' copy-protect is a risk because it is backwards from every other
magnetic medium I have ever encountered.  The standard is: You insert something
to permit writing and remove it to protect.  This is true for:

-9-track tape (write rings)
-VHS video cassette
-audio cassette
-8" floppy
-3.5" floppy

How come 5.25" floppies are backwards?

--Bruce  213/333-3538

Re: Failsafe mode for 3.5" Floppies

Andrew Klossner <>
Tue, 10 Sep 91 13:03:38 PDT
    "If dust prohibits sensing the position, or the detector/light
    source fails, the drive will incorrectly assume that the disk
    should be writable."

The RISK of assuming a particular implementation.  My Panasonic 3.5"
floppy disk drive senses the tab position by attempting to insert a
metal probe into the hole.  A successful insertion means that the disk
can be written.  The likely failure modes would falsely indicate
unsuccessful insertion, i.e., write prohibited.

  -=- Andrew Klossner  (

Re: Number of virus events dropping

Mark Hittinger <>
Sun, 8 Sep 91 21:06:36 -0400
I noted a comment in Cliff Stoll's message that he had the perception that
virus events and interest were kind of winding down.  I just wanted to comment
that, indeed, the messages-per-week posted on some of the local hacker bbs
virus groups has been dropping off steadily for months.  In one case the
"group" was deleted to make room for something else!

Humanity can only write so many payroll programs right?  Most viruses seem to
be re-hashes of existing ones.  Perhaps the fun is deflating?

The idea of a helpful virus is an interesting one.  Perhaps one that would
sense when your PC is locked up and warm-reboot?  HA.  I suppose that a helpful
virus would really be called a commercial TSR?

Mark Hittinger [answ.machine] (606)-272-2424  PO BOX 43358 Middletown, KY 40243

Re: Prize for Most Useful Computer Virus

Raymond Chen <>
Sun, 8 Sep 91 18:48:15 PDT
In <RISKS DIGEST 12.27> Cliff Stoll retells Fred Cohen's article which
describes how viruses and virus-like programs can be beneficial.

>automated bill-collectors, where, "each bill collector virus is a
>small program designed to collect one bill"; this program modifies
>itself depending on the debtor's response.  [...]  maintenance
>viruses which dispose of temporary files or hung programs.

I fail to see how these programs are virus-like.  The first is a self-
modifying program, and the second is what might be called a daemon.
Neither program is (or in the second example, needs to be) self-reproducing.

The only example of a `beneficial virus' I can think of is the one that was
released to fight another virus, namely the `Animals' program.  The problem
with viruses of either sort (in my unqualified opinion) is that once
released, they are hard to exterminate.

Another (more likely?) possibility is that I'm completely misunderstanding
the brief excerpt from Dr. Cohen's article.

Re: Prize for Most Useful Computer Virus

Richard A. Schumacher <>
Mon, 9 Sep 1991 17:56:02 GMT
I wonder whether Dr. Cohen's bill collector virus included a provision for an
audit trail, say by appending a record of every transaction to a database? His
"The Sciences" article mentions no such device, and indeed boasts the lack of
any large permanent database as an advantage. Feature or bug?

RE: Prize for Most Useful Computer Virus

Dave Butterfield <>
Mon, 9 Sep 91 15:20:32 -0700
I don't know about the *most* useful, but one very useful virus would be a
virus that identifies and destroys other viruses.  I suppose it would have to
be more virulent that the others.

Whoever implements this, please don't forget to program in some appropriate
self-destruct condition...

(Maybe there should be an RFC to cover that topic.)

It is RISKy to believe that Averages are `average'

Tue, 10 Sep 91 12:52 CST
desint!geoff@uunet.UU.NET (Geoff Kuenning) writes:

"Remember that, by definition, 50% of the population is of below-average

   [David goes on to shoot down this old war-horse... once again... I
   truncated the rest of his message, but would like to remind our contributors
   that it really helps if you are alert enough to avoid the mistakes that
   have already been kicked around in back issues.  See Mark Seecof's note in
   RISKS-12.11 that included counterexamples from Tim Smith and Jeremy
   Grodberg...  And thanks to those of you who are on your toes.  PGN]

Seventh Annual Conference on Computer Assurance

James Bret Michael <>
Mon, 9 Sep 91 11:32:59 -0400
            CALL FOR PAPERS
    Seventh Annual Conference on Computer Assurance

   The Seventh Annual Conference on Computer Assurance (COMPASS), sponsored by
the Institute of Electrical and Electronic Engineers and IEEE Aerospace and
Electronic Systems Society, in cooperation with the British Computer Society,
will be held at the National Institute for Standards and Technology in
Gaithersburg, Maryland, USA, June 15-18, 1992.  The purpose of this conference
is to bridge the gap between emerging technology for computer assurance from
research laboratories into industrial computer systems development.  Papers may
present original research on theoretical aspects and applications of technology
to assured computing, or may be reports detailing experiments, evaluations, and
open problems in the use of new technologies for computer assurance.  Typical
but not exclusive topics of interest include:

  * Models and modelling (process, mathematical, and requirements models)
  * Formal approaches (proofs of correspondence, formal specifications,
      and IV&V)
  * Experiences with assurance (illustrative examples from communications,
      energy, financial, medical, military, transportation, and other
      types of systems)

   Authors are requested to send five single-sided copies of their papers (not
exceeding 7,500 words) to the program chair by January 10, 1992.  If available,
an electronic mail address for the contact author should be included.  Papers
submitted simultaneously to another conference with published proceedings are
disqualified.  Papers will be refereed by the Program Committee and will be
returned with comments.  Accepted papers will be published in the proceedings.

   Papers due:          January 10, 1992
   Notification of acceptance:  March 7, 1992
   Camera-ready paper due:  April 1, 1992
   Conference:          June 15-18, 1992

   Additional information about the COMPASS '92 can be obtained from the
General Chair.  All inquiries concerning paper submissions should be addressed
to the Program Chair.

Robert Ayers            Dr. Edgar H. Sibley
ARINC Research Corporation  Department of Information and
2551 Riva Road            Software Systems Engineering
Annapolis, MD 21401 USA     George Mason University
voice:  (301)266-4741       4400 University Drive
fax:  (301)266-4040     Fairfax, VA 22030-4444 USA
                (703)993-1640, or

Please report problems with the web pages to the maintainer