Subject: RISKS DIGEST 11.84 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 6 June 1991 Volume 11 : Issue 84 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: MAN CATCHES COMPUTER VIRUS! A new computer risk? (WWN) (Mike Corbett) WWN Strikes Again! (PGN) VIPER and formal specification of hardware (anonymous) Patriot missile failure followup (Martin Minow) Re: Lauda 767 crash (PGN, Brian Hayes) Re: Thrust reversers (Jim Sims) Re: Lauda Crash -- an old C-47 incident (Wm Randolph Franklin) Thinking like a manager (Challenger) (Ed Nilges) Compression losses, microphoto artifacts (Leslie DeGroff) Erasing Calif license mag strip (Mark Seecof) Re: Digital Fingerprints in California (Gary Greene, Alan Dahl, Mike Morris) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 11, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Thu, 6 Jun 91 14:09:31 EDT From: mcc@moscom.com (Mike Corbett) Subject: "MAN CATCHES COMPUTER VIRUS!" -- A new computer risk? [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] ------------------------------ Date: Thu, 06 Jun 91 19:00:00 PDT From: Peter G. Neumann Subject: Re: WWN Strikes Again!? 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 ------------------------------ Date: Thu, 06 Jun 91 12:17:33 xxx From: Anonymous Subject: VIPER and formal specification of hardware 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. ------------------------------ Date: Thu, 6 Jun 91 06:19:22 PDT From: Martin Minow 06-Jun-1991 0908 Subject: Patriot missile failure followup (More on RISKS-11.70) 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 garbage-collect. Martin Minow minow@ranger.enet.dec.com ------------------------------ Date: Thu, 6 Jun 91 8:29:42 PDT From: "Peter G. Neumann" Subject: Lauda 767 crash 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 follows: 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 convenience). 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. ------------------------------ Date: Wed, 5 Jun 91 19:58:05 -0400 From: Brian Hayes - Sigma Xi Subject: Lauda Air flight data 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] ------------------------------ Date: 6 Jun 91 22:50:08 GMT From: sims@starbase.mitre.org (Jim Sims) Subject: Re: Thrust reversers 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 ------------------------------ Date: 5 Jun 91 21:59:53 GMT From: wrf@mab.ecse.rpi.edu (Wm Randolph Franklin) Subject: Re: Lauda Air Crash -- an old C-47 incident 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 ------------------------------ Date: Thu, 06 Jun 91 17:09:58 EDT From: Ed Nilges Subject: Thinking like a manager (Challenger) 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." ------------------------------ Date: Wed, 5 Jun 91 13:49:06 PDT From: Leslie DeGroff Subject: Compression losses, microphoto artifacts 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 ------------------------------ Date: Thu, 6 Jun 91 15:25:38 -0700 From: Mark Seecof Subject: Erasing Calif license mag strip (Re: Nishioka, RISKS-11.63 [and .09) 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 human-readable. 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.] ------------------------------ Date: Wed, 5 Jun 91 13:40:19 PDT From: Gary Greene Subject: Re: Digital Fingerprints in California (Caplinger, RISKS-11.82) >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 ------------------------------ Date: Wed, 5 Jun 91 15:12:37 PDT From: morpho!alan@uunet.UU.NET (Alan Dahl) Subject: Re: Digital Fingerprints in California 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!...) ------------------------------ Date: Thu, 6 Jun 1991 16:30:37 GMT From: morris@grian.cps.altadena.ca.us (Mike Morris) Subject: Re: Digital Fingerprints in California (Robinson, RISKS-11.83) >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 >quickly... 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 ------------------------------ End of RISKS-FORUM Digest 11.84 ************************