| 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: http://catless.ncl.ac.uk/Risks/11.84.html | |
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
MAN CATCHES COMPUTER VIRUS! A new computer risk? (WWN)
WWN Strikes Again!
VIPER and formal specification of hardware (anonymous)
Patriot missile failure followup
Re: Lauda 767 crash
Re: Thrust reversers
Re: Lauda Crash -- an old C-47 incident
Thinking like a manager (Challenger)
Compression losses, microphoto artifacts
Erasing Calif license mag strip
Re: Digital Fingerprints in California
[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]
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
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.
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
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.
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]
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
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
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."
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
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 <marks@latimes.com>
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.]
>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
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!...)
>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
| This page was copied from: | http://catless.ncl.ac.uk/Risks/11.84.html |
| COPY! | |
| COPY! | |
|
by Michael Blume |