University of Bielefeld -  Faculty of technology
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D.
Back to Abstracts of References and Incidents Back to Root
This page was copied from:

Previous Issue Index Next Issue Info Searching Submit Article

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 11, Issue 84

Thursday 6 June 1991


o MAN CATCHES COMPUTER VIRUS! A new computer risk? (WWN)
Mike Corbett
o WWN Strikes Again!
o VIPER and formal specification of hardware (anonymous)
o Patriot missile failure followup
Martin Minow
o Re: Lauda 767 crash
Brian Hayes
o Re: Thrust reversers
Jim Sims
o Re: Lauda Crash -- an old C-47 incident
Wm Randolph Franklin
o Thinking like a manager (Challenger)
Ed Nilges
o Compression losses, microphoto artifacts
Leslie DeGroff
o Erasing Calif license mag strip
Mark Seecof
o Re: Digital Fingerprints in California
Gary Greene
Alan Dahl
Mike Morris

"MAN CATCHES COMPUTER VIRUS!" -- A new computer risk?

Mike Corbett < >
Thu, 6 Jun 91 14:09:31 EDT
                                   [WWN's Computer Story Generator Strikes Again!]
                            MAN CATCHES COMPUTER VIRUS!
                     Bizarre illness jamming up his brain waves!
     Caption: SICK COMPUTER passed on a bizarre virus to programmer John Stevens,
     above, after it became ill from an infected software program.
     By Michael Todd, Special Correspondent, {Weekly World News}, 18 June 1991
        John Stevens has a lot in common with his home computer: Both think
     logically, both like numbers and both are sick with a virus - the same virus!
     Stevens, a computer programmer who works out of his home in a Philadelphia
     suburb, is convinced his lingering and debilitating illness is something he got
     from his sick computer.  And the victim's doctor agrees.  "I've run every test
     I can think of to trace the origin of his illness," said Dr. Mark Fordland.
     "He has a virus, but it's not like any virus I've ever seen."
        Stevens, 32, said his computer began to show signs of a virus - a software
     program designed to eat up an destroy other software data - about a week before
     he got sick.  "I was careless about borrowing software programs from other
     people I didn't know well," Stevens admits.
        Dr. Fordland, himself a computer expert, agrees.  "Borrowing software
     programs from friends and strangers is like having sex with someone you don't
     know well.  When you sleep with someone, you sleep with everyone they've ever
     slept with.  When you borrow someone's software program, you're connected to
     everyone who's ever used that program."  Dr. Fordland concludes that Stevens'
     symptoms are identical to that of a software virus' attack on a computer.
     "Stevens has become forgetful, like something is eating up his memory, his
     data.  He has less and less energy.  He can't hold onto thoughts.  Even an EEG
     (electroencephalogram) of his brain waves keeps changing.  It's becoming more
     and more erratic.  "This virus could just eat him up until his mind is a blank
     and he's like a vegetable," the doctor said.
        [Wow!  Sure brings home the point that we should all practice "safe
         computing".  Mike]

Re: WWN Strikes Again!?

Peter G. Neumann < >
Thu, 06 Jun 91 19:00:00 PDT
          As a veganophile, I take offense to WWN's insulting the vegetable kingdom.
          But, stay tuned for the sequel, when WWN discovers vegetable matter is not
          so dumb as it looks, and can actually be used in building computers:
            Venus flytraps as input devices?
            High-Q-cumbers (without leekage) and toroidal turnips
              (/root/a/bagels?) as storage devices?
            Phototropic switches, albeet somewhat slow in changing state?
              (Sun tried tomatoes, but they wouldn't work!)
            Poly-Okramatic display screens?
            Tree-structured directories using live bee trees?
            Artificially intelligent roboDENDRALs? (apologies to HERB Simon)
            Century plants for long-term archiving?
          Let the buyer beware?  No, let the celery beware!
          By the way, when Ada Lovelace fixed the computer system, 
            she became a Babbage-Patch Doll.
          Don't forget the net reprimand, TOO-MANY-HOPS [SPOIL THE BREATH?],
          and please pardon my (corny?) ingrained rye humor.
          It's gone but not ergotten.  (There must be a fungus amongus.)  PGN

VIPER and formal specification of hardware

< Anonymous >
Thu, 06 Jun 91 12:17:33 xxx
     A story I'd heard about the VIPER chip from someone who had been associated
     with it was that after the designers at RSRE had taken the high level design
     and gone on to produce an ELLA description of it, they had to send that out to
     the fabricators.  A couple of companies where chosen to fabricate it, on gate
     arrays I believe.  Apparently the engineers at one of the companies had a go at
     hand-optimising the layout, thus endangering all the previous work!
     A previous attempt at producing a formally specified CPU at Cambridge
     University could have run into some problems when it was realised -- during
     fabrication -- that they'd forgotten to spec out fully the startup state of the
     computer.  Fortunately the process used ensured that the chip would start up in
     a usable state.
     In my own experience at formally specifying hardware I've found that its good
     for the abstract behaviour of computers, such as how the ALU should behave.  You
     can take a high level spec and synthesise the same behaviour from the
     specifications of 74-series TTL and PALS.  What you can't do is design out the
     failure cases.  For a software routine you can give preconditions for all
     arguments and then check them at the start of each invocation, calling error
     handlers when the conditions fail.  It's hard to do the same thing for hardware
     when the preconditions include things like the supply voltage being within 1/2V
     of +5V, or the timing constraints of signal setup and hold times.  When these
     things are violated the system does tend to behave extremely badly.
     Conclusion: Formal Specification and Verification of Hardware are unlikely to
     ever be able to guarantee the reliable operation of computers, except within
     clearly defined constraints.
     This is no reason not to try, however.  I mean, imagine if a big company like,
     say, Intel, produced a microprocessor, called something like an i486, with a
     bug in its maths. Imagine the trouble that would cause?  Perhaps if the formal
     techniques will someday be able to handle complex chips such problems will
     disappear, or at least be reduced.

Patriot missile failure followup (More on RISKS-11.70)

Martin Minow 06-Jun-1991 0908 < >
Thu, 6 Jun 91 06:19:22 PDT
     This is heavily edited from an AP article in the Boston Globe, 6-June-1991:
       The computer in the Patriot battery whose radar had picked up the
       incoming Scud failed to track the missile... Thus no computer instructions
       were given to the Patriot missiles and none were launched, the Army said.
       The Patriot computer screen did not show an incoming Scud because the
       computer software could not calculate the missile's path quickly enough.
       This was attributed to two factors the Patriot systems had not previously
       encountered in Saudi Arabia: The computer had operated continuously for four
       days prior to the moment of attack, and a faster than usual Scud missile speed.
       The lengthy period of nonstop operation had reduced the computer's capacity to
       make calculations. ....
       Improved computer software to correct the Patriot problem arrived in Saudi
       Arabia ... one day before the attack, but priority for installing the new
       tapes was given to Patriot batteries deployed closer to Iraq. ...
       Army officials at Huntsville, Ala., site of the Patriot project office, had
       disclosed privately last month that a computer software glitch was to blame
       for the failure...  It had not previously been made known that the Army knew
       of the Patriot computer problem before the fatal attack.
     Huh? Bit rot? Or, perhaps, a main memory failure that caused the program to
     swap/page/thrash and consequently not be able to keep relevant data in main
     memory.  Hmm, maybe it was keeping a continuous event log in memory.  Or, maybe
     the Patriot software was written in Lisp and it chose the wrong time to
                              Martin Minow

Lauda 767 crash

"Peter G. Neumann" < >
Thu, 6 Jun 91 8:29:42 PDT
     I am told that Boeing has a generic specification for the engines, which all
     engine manufacturers have to follow. The thrust reversers are activated as
       Activation occurs with a 28-volt output from a four-input AND gate. This AND
     is not ttl, it is diode logic at 28 volts, and very simple.
       One of the inputs comes from the FADEC. It is a combination of "engines at
     idle" and "weight on wheels" (the latter is combined in the FADEC for
       One input comes directly from the setting of the throttle lever. It is a
     microswitch on the reverse position on the throttle quadrant.
       One input comes from the spoilers. It is a microswitch detecting that the
     spoilers are fully deployed.
       One input comes from the flaps. It is a microswitch detecting that the flaps
     are at 25 degrees or more.
     This is seen to conform to best practice. The computer system is not critical,
     and the rest of the system design is very simple. There seems to be a common
     point in the AND gate, but the reliability of such a simple system should be
     easy to establish.  If 28 volts somehow got beyond the AND, then presumably the
     reverser would deploy, but such speculation seems idle at present.  It doesn't
     feel like a FADEC failure.  BUT, if the reported cockpit failure signal somehow
     reports the activation of the three non-FADEC signals, then the FADEC becomes
     critical; but how then to explain what would seem to be a triple failure
     followed by a FADEC failure?  The mystery remains.

Lauda Air flight data

Brian Hayes - Sigma Xi < >
Wed, 5 Jun 91 19:58:05 -0400
     Several RISKS readers have mentioned that the flight-data recorder transcript
     from the crashed Lauda Air 767 seems to be unreadable. But some of the flight
     data may be available from another source. Quoth Aviation Week (June 3, p. 92):
     The aircraft's Loral-Fairchild flight data recorder and Sunstrand cockpit voice
     recorder have been recovered and appear to be in good condition.
     Authorities already have vital recordings of the Lauda transport's performance
     parameters up to the moment of the crash. Boeing 767s are equipped with the
     advanced Arinc Communications Addressing and Reporting System (ACARS). It
     automatically updates, batches and relays aircraft and engine performance and
     maintenance information to ground stations every few seconds via private VHF or
     HF radio networks. This information is forwarded to Lauda maintenance offices
     in Vienna.
                   [Also reported by John Knight, jck@neptune.cs.Virginia.EDU]

Re: Thrust reversers

Jim Sims < >
6 Jun 91 22:50:08 GMT
     Not *all* use of thrust reversers inflight is unintentional or catastrophic.
     NASA was (and prob still is) using a Gulfstream G-II (when I worked there) as a
     Shuttle landing simulator.
     To simulate the shuttle's glidepath, you take a G-II up to altitude, deploy
     full flaps, drop the landing gear ('dirty' the plane), and then apply full
     thrust reversers. Yes, it drops just like a rock/shuttle...
     DECUS AI SIG Symposium Representative    The MITRE Corporation
     7525 Colshire Drive   MS W418            McLean, Va.   22015

Re: Lauda Air Crash -- an old C-47 incident

Wm Randolph Franklin < >
5 Jun 91 21:59:53 GMT
     Some decades ago, a C-47 (I think) hit Wright Peak in northern New York State,
     a popular hiking spot.  There are a few big pieces, and thousands of pieces
     less than an inch square scattered over, say, a half-mile area.  Much of that
     plane shattered like glass.  A larger plane with large, full, fuel tanks would
     be scattered farther.
     As for the observed flare, if the observers are accurate, which is always
     doubtful in disasters, maybe the reversed thrust tore the engine loose, or a
     piece of the engine hit the fuselage.
     						   Wm. Randolph Franklin
     Wrfrankl@Rpitsmts.bitnet     (518) 276-6077
     ECSE Dept., 6026 JEC, Rensselaer Polytechnic Inst, Troy NY, 12180

Thinking like a manager (Challenger)

Ed Nilges < >
Thu, 06 Jun 91 17:09:58 EDT
     From Michael Davis' article "Thinking Like an Engineer: the Place of a Code of
     Ethics in the Practice of a Profession", Philosophy and Public Affairs, Spring
     1991, Vol. 20 #2:
        "Lund's first response was to repeat his objections.  But then Mason said
        something that made him think again.  Mason asked him to THINK LIKE A
        MANAGER INSTEAD OF AN ENGINEER (the exact words seemed to have been "take
        off your engineering hat and put on your management hat.")  Lund did and
        changed his mind. The next morning the shuttle exploded, killing all aboard.
        An O-ring had failed."

Compression losses, microphoto artifacts

Wed, 5 Jun 91 13:49:06 PDT
       An aside related issue to compression losses in photographic data is that of
     photographic or processing "artifacts".  A recent issue of Science had an
     article on problems of carbon chains being misinterpreted in a number of cases
     in electron and various scanning microscopy, this was primarily about physical
     "artifacts" but when your dealing with highly (computer) processed signals
     looking for edges, low contrast/low threshold regions you have issues (and
     risks) with putting things in that don't really exist or the misinterpretation
     of physical artifacts from the preparation and handling of specimens.  As a big
     deal with all kinds of microscopy this has implications for attempts to
     automate or semiautomate medical work such as pap smears.  Recent articles in
     CA, have made a big issue about risks with the quality of such services...
        Like several other posters, I think that the real problem is going to be
     "litigate if there is a chance of winning" law system and "devil we know vs the
     one we don't, conservative" medical system rather than technical issues... The
     real limit in most cases is the human in the loop interpreting!!!! My guess is
     that within ten years technically the scanners, computers and softwares will be
     available to have annual whole body scans with resolutions in the cubic
     millimeter scale and have the ability to early screen for most cancers, most
     hidden circulatory problems when most of them are minor surgery rather than
     life or death medical heroics. The capabilities of the medical system to use
     it, and our resource allocations to deploy them probably with triple that to 30
     years before general use. Les DeGroff

Erasing Calif license mag strip (Re: Nishioka, RISKS-11.63 [and .09)

Mark Seecof < >
Thu, 6 Jun 91 15:25:38 -0700
     I still have an "old" California driver's license (it'll expire in late '92).
     I fear that when I get a "new" one, the magnetic strip on the back may
     accidentally be erased by some chance encounter with a strong magnetic field.
     After all, I've had credit-card strips fail.
     (Side notes: when credit-card strips fail the card-issuers don't rewrite the
     mag strip, they just give you a whole new card.  Actually, failed strips are a
     problem for merchants as well as credit-card users because merchants get a
     discount on the fee they pay to the bank if they "swipe" a card rather than
     just taking an imprint).
     Because it is unlawful to "alter any driver's license in any manner not
     authorized..." (CVC 14610(h)) a police officer would have probable cause to
     arrest the holder of a license with a bad mag strip if he became aware of that
     circumstance (after, say, discovering that a portable reader can't read the
     strip).  Note that a police officer doesn't need probable cause to inspect your
     driver's license if you appear to be in control of an automobile (CVC 12951).
     (Refusing to produce the license is an offense.)  Now, unless the prosecutor
     could prove that the erasure was deliberate, the license-holder probably
     wouldn't be convicted but would already have spent the night in jail, or if
     cited and released would at least have had to come to court.  Worse, a license
     holder might be violating the law and not know it, because the strip isn't
     Any system that might code information on the mag strip that didn't appear in
     human-readable form on the license card is inherently evil.  Data on mag strips
     is fragile.  I don't see how I'll be able to guard against the accidental
     erasure of the mag strip on any license issued to me.  Given my innocent
     predilection for toying with permanent magnets and the fact that I work with
     various sorts of electrical and electronic equipment, who can say when an
     accidental erasure might occur?  Why, it could even happen within minutes of my
     receipt of the new license!
     I hope that the Legislature will see the RISKS here and change the law to
     exclude the data on driver's license mag strips from protection by the
     anti-tampering rules.
                                     Mark Seecof <>
     My opinions are not those of my employer.  (My employer's opinions appear on
     the third-from-last page of the Metro Section weekdays or of the Opinion
     Section on Sunday.)
                     [Reminder: Alan Nishioka discusses the format in RISKS-11.63.]

Re: Digital Fingerprints in California (Caplinger, RISKS-11.82)

Gary Greene < >
Wed, 5 Jun 91 13:40:19 PDT
     >I recently applied for a California driver's license, and was surprised to
     >learn that the fingerprinting required for a license (right thumbprint) was now
     >done by a digital scanner instead of with paper and ink pad.  
     Seems to me I've heard the above stated about a thumb print being required on
     California licenses in Risks before, however I just renewed my license in
     person (I'm an inveterate procrastinator about some things and had to go in to
     get a renewal by my deadline), a new photo was shot, but no thumb print taken
     ...nor have I ever submitted a thumb print to them in the past.  I received my
     nice new card with the magnetic stripe and holograph several weeks ago.
     >...  Anybody know more about the California database, or how viable thumbprint
      matching may be?  Would one expect many false matches using just a thumbprint?
      How many other states require fingerprints for driver's licenses, and does any
      other use digital scanners?
     I'm not a specialist whose comments would bear relevancy on the above issue,
     but my impression is that a thumb print is useful mostly for general i.d.
     purposes, since it is only one digit.  It is true that so long as there are
     enough match points that any finger can be used by a police agency to establish
     identity, however most latent prints from a crime scene are partials and it is
     rare that a full set of usable prints can be lifted.  Not being a police
     officer I can't comment on the frequency that a thumb print is available.
     Current commercial scanners of reasonable price can now scan at about 1200 dpi
     (scanners under $7-8k).  This ought to be good enough resolution to avoid
     mismatching i.d.
     My photo was still taken with the old optical camera by my local DMV office.
     Of course, this doesn't prevent them from scanning the photo in later, but
     from the appearance of mine this doesn't seem to have occurred.
     While on the one hand I hate government intrusion and dislike the idea of a
     national or even state police data base, having been the victim of grand theft
     once I can appreciate the availability of some way that police can identify
     criminals in the event of crime.  The officer who dusted my premises (at my
     request) wasn't hopeful that the prints would be useful.  Unless the person who
     commits the crime has a prior booking record there is no way to match the
     prints, even if the computer base and time to match the prints is available
     (neither were in my case ...the prints went into the case file and the officer
     said that the only person who might ever look at them would be an officer
     trying to match up a pattern of similar crimes with a suspect; in short someone
     with a hobby-case).
     In order for a California DMV thumb print to be used by a police agency it
     appears that a number of prior things need to happen.  First, *all* crime
     records and other police records need to be consolidated into one data base,
     on-line at a central location.  That's a lot of paper!  We are only now
     reaching the point where this is practical technologically (i.e., companies
     like mine, Unisys, are marketing such paperless systems to banks now).  The
     second thing necessary is that a budget be found to scan in this massive
     records data base from the existing paper files.  This is also no mean task,
     and would require more than a few manhours to accomplish.  The equipment budget
     to set up the system would be expensive also, though that part of the task
     would be manageable during normal economic times.  Since the state and local
     governments here in California are currently bankrupt for all practical purpose
     I doubt that we will see any move in this direction in the forseeable future.
     Consolidating all this with the DMV system would seem to multiply the prac-
     ticalities of the task beyond reasonable economic-political considerations.
     You think the Prop 13 revolt was bad?  This would put the Jarvis-Gann people in
     bed with the ACLU and several others.  I can here several politicians saying
     !!wow!! with glistening palms while the bureaucrats shudder. :->
     Gary Greene, Unisys/Convergent Technology, San Jose, California

Re: Digital Fingerprints in California

Alan Dahl < morpho!alan@uunet.UU.NET >
Wed, 5 Jun 91 15:12:37 PDT
     Sorry to burst your balloon, but current matching technology is perfectly able
     to search a database of the size indicated (20,000,000 1-finger records).  We
     are in the process of converting our system to a newer 2-times faster machine
     that should make this sort of search even easier.  With a MORPHO AFIS
     (Automated Fingerprint Identification System) the search would not be too
     labor-intensive either.  Our system is not very labor intensive at all.  It is
     true, however, that some other companies' AFIS systems are too labor intensive
     for this sort of work.
     We currently have an installation in New York with over 4.5-million 10-finger
     records and regularly run hundreds of latent and tenprint searches a day
     against this record database.  Average tenprint to tenprint matching time is
     under 2 minutes/search.  With a 20-million record database and the same
     hardware matching time would increase to about 3 minutes or so per search.
     Adding more hardware could shorten this down to 30 seconds if the customer
     desired.  The current accuracy rate is 98% matched in the first position with
     most of the other 2 percent in the second position.  Whether that print is a
     thumbprint or not will not affect the accuracy of the search at all.
     We have talked to the State of California DMV about installing an AFIS system
     for commercial driver's licenses only.  As far as I know everything is on
     hold and there are no plans at this time to purchase such a system either
     from us, or our competitors.
     A combination AFIS/mugshot system will probably be a reality in the near
     future, many jurisdictions desire such a system.
     There are serious legal ramifications to using driver's license fingerprint
     data for anything else besides checking for duplicate licenses and aliases.
     Most states have laws that state that someone must be suspected of a crime
     before their prints can be searched against a criminal database.  It is
     likewise illegal to search a suspected criminal's prints against a database of
     people who have not been suspected of a crime (such as databases of applicants
     for gun permits or police job applicants or driver's licenses).  If the State
     of California passed a law legalizing such action and the Supreme Court let it
     stand (not too likely, I hope), it would technically be easy to implement such
     a system.
     What is more worrisome is that the driver's license data could perhaps be used
     for checking the legality of applicants for welfare, food stamps, and other
     non-criminal uses.
     Alan Dahl, North American MORPHO Systems, 1145 Broadway Plaza, Tacoma, WA.
     98402    PH:  1 (206) 593-8021       ...uw-beaver!amc-gw!morpho!alan
                                        (please DO NOT use uunet!amc-gw!...)

Re: Digital Fingerprints in California (Robinson, RISKS-11.83)

Mike Morris < >
Thu, 6 Jun 1991 16:30:37 GMT
     >A while ago, I read in RISKS of a woman who obtained fraudulent identification
     >and spent large amounts of another woman's credit.  The risk of fraudulent
     >identification is, IMHO, far greater than the risk of positive identification.
     There was a case widely reported of a rather-well-off lady who obtained
     something like 15 fraudulent IDs and got on the welfare rolls with most of
     them.  When she was caught, it caused a _big_ stink.
     >... I don't see how the thumbprint/photo database would allow law enforcement
          to threaten my rights or privacy in any novel manner.
     You don't read much futuristic SF do you...  Lets say that a video tape was
     made of a mugging - a Rodney King-type video tape, only different.  Now image
     enhance it and run it against the data base and come up with probable IDs.
     >What does get me sort of nervous is the magnetic stripe on the back.  The only
     >advantage I can see to that is the ability to process a lot of people really
     There was a writeup in ca.driving a while back on the format and what's in it
     (no, sorry, I dodn't save it).  It's essentially 3 tracks of the same info that
     is on the face of the license.  The cops will be getting hand-held ticket
     printers with "swipe" card readers for accuracy.  The current method of hand
     copying the data leads to inaccuracies.  Also the ticket printers will be
     uploaded regularly with outstanding warrant info.
     Mike Morris   WA6ILQ  PO Box 1130  Arcadia, CA. 91077  818-447-7052 evenings

Previous Issue Index Next Issue Info Searching Submit Article

Report problems with the web pages to
This page was copied from:
Last modification on 1999-06-15
by Michael Blume