# Forum on Risks to the Public in Computers and Related Systems

## Contents

Ex-DMV worker admits altering driving records for money
Vireday
Software migration at Johnson Space Center
Joe Bouchard
European Ideal Embraces Harmonised Pornography
Brian Randell
Prison Phone Phraud (or The RISKS of Spanish)
Jim Flanagan
"Peace Patent" and "Colossus: The Forbin Project"
Lauren Weinstein
UCSC to install touch-tone registration (HELP WANTED)
Darrell Long
Re: Ada Code Formatters (... old software)
David Parnas
Re: Encryption Exportability, by Clark Weissman
Carl Ellison
Re: Fiber optics can spontaneously destroy themselves!
Paul Leyland
Re: Safer flying through fly-by-wire
Randal L. Schwartz
Re: Friendly'' (?) viruses
Bertrand Meyer
Re: AT&T Outages
Peter G. Rose
Re: RISKS of Highway warning signs
Steven Philipson
Arthur Hamlin
Richard Thomsen
Bob Haar
Keith Henson
Info on RISKS (comp.risks)

### Ex-DMV worker admits altering driving records for money

~Vireday <rvireday@pldote.intel.com>
Thu, 10 Oct 91 08:39:32 PDT
Excerpts from "The Sacramento Bee", Friday, October 4, 1991.  The RISKS are
more than obvious.  (Didn't something similar already happen in Great Britain?)

It is not explained how they found out about the alterations.  Probably
followed a paper trail, or discrepencies in backup logs.  If that is so, what
about all these pen-point computers about to hit the cop market?  Will this
increase the risk of losing this kind of "evidence"?

Ex-DMV worker admits altering driving records for money

A former technician for the [California] Department of Motor Vehicles admitted
in court Thursday that she deleted bad driving records of a number of
guilty to 10 counts of illegally using the DMV computer for the purpose of
altering, damaging or destroying data.  Nineteen additional counts were
dismissed.  Proceedings against her co-defendant, Donald H. Stables, were
continued to Oct. 24.  He is charged with 48 counts involving computer fraud,
bribery, falsification of government documents and conspiracy.

According to court records, Stables, an insurance agent in Yreka, allegedly had
been receiving fees of up to $2500 to arrange the obliteration of accident reports, drunken-driving arrests, suspensions and other violations on his clients' DMV records. Lopez was his contact at the department, according to documents, and she received between$400 and $500 for each transaction. ... [The plea bargain terms Lopez has arranged are six years of formal probation, 60 days in the county jail, a fine of$10,000, and to testify against Stables
if need be.]



### Software migration at Johnson Space Center

Joe Bouchard <texsun.Central!ioscc!bouchard@fernwood.UUCP>
9 Oct 91 17:48:31 CDT (Wed)
The managers at NASA/JSC (Johnson Space Center, Houston, TX) seem to be
underestimating the RISKS associated with migrating a mature software product
to a completely new environment.

There is a move afoot to migrate the SMS (Shuttle Mission Simulator) from the
Unisys 1100/90 - Perkin Elmer 8/16 equipment it's currently running on to
another platform (not completely defined yet).  The reasons for doing the
migration sound something like "we need to get off that old mainframe equipment
and into the modern age of Unix, multiple workstations, etc.  Or maybe an
modern (IBM) mainframe."

The justification for going through the effort (and believe me, it's going to
be monumental) is improved uptime due to improved hardware and software
reliability, ease in implementing changes, and performance (the 1100 it's on
doesn't have a high MIP rating, and we all know how truly useful MIPs are to
compare dissimilar hardware/software).  Upgrading the current equipment and/or
software environment is not currently being considered seriously (Unisys isn't
POPULAR with the big wigs at JSC, IBM & Unix anything are).

Problem one: the numbers being used to do the justification seem to be largely
imaginary (I'm not close enough to the project to tell for sure).  Sort of ...
"Everyone knows that mainframes are unreliable and workstations are good.  Rate
the mainframe 10 failures per ?? (based on real data) and rate the workstation
system 3 per ?? (based on who knows?).  This will save us big \$."  Even if
the numbers are based in something resembling a scientific study, they are
likely to be based on MATURE systems.  Anyone who has been through a major
conversion effort can tell you just how long it takes to get millions of lines
of real-time simulation software to the same maturity on another box,
especially a very different kind of box (the Shuttle may be retired by then).

At the time SMS was developed (more than 12 years ago), Univac (later Sperry,
later Unisys) was the only vendor that had developed real time software
processing to a sufficient maturity on a large enough box to get the job done
(I believe they were the only ones to complete the pilot project successfully,
but I wasn't around then).  Since then, the software has undergone extensive
growth.  This system is complicated to the point that moving it to another
platform will be practically as difficult as redeveloping it from scratch.

Problem two: none of the destination systems being discussed have demonstrated
that kind of real-time software processing capability.  Problem three: none (or
almost none) of the programmers currently working on SMS has any experience
with any of the new systems.  There is a gigantic risk in going from the known
into the unknown.  This risk is unjustifiable when significant improvements can
be made in the current environment.

Unisys 1100-series equipment, from the smallest (2200/100, desk sized small
business system) to the largest (2200/600, big mainframe), runs the same
software across the entire line with NO modifications required.  Such a large
range of compatible processing power is unavailable from any other vendor (the
Unisys A-series has a somewhat wider range).  Since the initial development of
SMS, the capabilities of both the hardware and system software of the
these improvements would be much less risky than moving to another platform,
but the lack of popularity of Unisys at JSC prevents it.  (Another of those
political correctness things.  Also a result of the government contractor
environment.  "We hired you to do what we tell you to do and nothing else.")
And all this at public expense without much accountability.

NOTE: I have been doing System Software support on 1100-series computers for
about 10 years and can't claim to be entirely unbiased.  I have done
programming on both personal computers (Apple, Commodore, IBM, etc.) and
mainframes (Honeywell, Unisys 1100/2200, some IBM), so I have an idea what it
takes to move conventional systems from one box/environment to another.  I
don't think the management at NASA does.



### European Ideal Embraces Harmonised Pornography

<Brian.Randell@newcastle.ac.uk>
Thu, 10 Oct 91 09:32:14 BST
  [The risks entailed in the attached article, quoted in full from the front
page of today's Independent, are perhaps not so much computer-related as
commission-related, but I thought I would "share them" (to use an American
phrase which always grates somewhat on British ears :-) with RISKS readers.

Brian Randell, Computing Laboratory, The University, Newcastle upon Tyne,
NE1 7RU, UK                PHONE = +44 91 222 7923  FAX = +44 91 222 8232]

European Ideal Embraces Harmonised Pornography,
by Andrew Marshall, West Europe Editor

The European Community has a new crusade: high technology pornography.  EC
commissioner Filipo Maria Pandolfi told the European Parliament in a letter
yesterday that the Commission is working on a code of conduct for the sex
industry.  Mr Pandolfi is the Telecommunications Commissioner, and does not
usually get involved with below-the-waist activities in a professional
capacity. But the modern pornographer is increasingly dependent on modems and
multiplexes [sic] rather than plain brown envelopes and hand-wound peepshow
machines.  And when Brussels hears the word "hi-tech", it reaches for a
directive.  "Such a Code of conduct would state ... rules for the information
industry ...  and administer the provision of information services of a
pornographic nature," says Mr Pandolfi's letter.

The pornography industry, as well as simple telephone chat lines and recorded
messages, has now developed much more complicated ways of sending pornographic
images along the line. Regulating these is something of a problem for
old-fashioned vice cops.  But when different individual member states develop
different approaches, this can interfere with more legitimate business
activities. So part of Mr Pandolfi's mission is to ensure that Nation shall
speak dirty unto Nation, because, as the Commission puts it, "discrepancies
between existing national regulations constitute a problem in establishing a
common market for information services". Let nobody keep apart heavy breathers
in Croydon and Cologne, lest they disrupt the single internal market.

Perhaps the commission is not aware of the risks in opening Pandolfi's box.
Will pornography have to be standardised, with French maid's uniforms
compulsory? Will there be heavily-subsidised industrial national champions in
pornography, allowing the Dirty Old Man to represent Euro-frotteurs?  Must
Naughty Fifi Tell All in eight languages?



### Prison Phone Phraud (or The RISKS of Spanish)

Jim Flanagan <flanagan@stat.washington.edu>
Thu, 10 Oct 91 16:51:16 -0700
This notice appeared in the University of Washington staff newspaper
University Week:

PHONE FRAUD

It recently was discovered that inmates from the Clallam Correctional
Center in Clallam Bay, WA have been using an automated phone system to
try to scam unsuspecting employees at the UW.

Fone America, the long-distance provider for the correctional center,
supplies anautomated service for collect calls. Inmates are supposed to
make recordings of their names to identify themselves to the called parties.
A recording should say, "If you will accept a collect call from...(name of

Fone America also supplies the same automates message in Spanish. In the
scam, inmates chose the Spanish option and record, in place of their names
"If you want to hear this message in English, press 33." They then call
a number at the UW an try to reach employees who will press 33 which
automatically accepts the collect calls. If the inmates get through, they
ask to be transferred to the outside operator or to the switchboard
operator. They will then attempt tp place long distance calls and have them
billed to campus phones.

Since late July, this scam has occourred a number of times. It is important
for University employees to recognize this or similar phone scams.

[The notice goes on to suggest ways to minimize the impact of phone fraud]

Jim Flanagan, Systems Programmer, UofW Statistics flanagan@stat.washington.edu



### "Peace Patent" and "Colossus: The Forbin Project"

Lauren Weinstein <lauren@vortex.com>
Wed, 9 Oct 91 12:08:02 PDT
Yes, indeed, the described "peace patent" is similar in some respects to the
basic concept behind the semi-classic film "Colossus: The Forbin Project"
(1970).  In the film, both the US and USSR put into place master control
computers to manage their nuclear arsenals.  Gimmick: the systems cannot be
turned off or disconnected (similar to 'The Doomsday Machine' from "Dr.
Strangelove") without blowing everything up.

The US computer (Colossus) realizes that there must be a Soviet computer
(Guardian) and demands a hookup (TCP/IP?  OSI?).  Classic line: "There is
another system."

Both sides let their computers talk for awhile.  There's an amusing sequence
where the two systems, starting with 0 and 1, build up a vocabulary and rapidly
increase the data rate.  The humans watching have an increasingly difficult
time keeping track of what the machines are saying to each other as the rate
increases.  Suddenly, the machines shift to a completely unknown protocol and
coding, and the humans have no idea what is going on between the machines.
They panic, and pull the plug on the connection.  Colossus (we see all this
from the US side) tries for a while to get a circuit back to Guardian over
various cable and satellite systems.  He can't.  He then simply demands that
the circuit be restored, or else he'll fire a missile.  In fact, as I recall he
does just that, as does Guardian.  The warheads are only destroyed (how?) when

There are a lot more goings on, including various other attempts to disconnect
the computers or disarm the warheads.  All fail.  The film ends with Colossus
and Guardian in total control of the world, and humans relegated to a position
of being, essentially, slaves to the machines.
--Lauren--



### UCSC to install touch-tone registration

<darrell@cse.ucsc.edu>
Thu, 10 Oct 91 14:57:20 -0700
UC Santa Cruz is going to install a touch-tone registration system.  Here's
your chance to prevent a RISK before it occurs.

Please send me any RISKS that you know of in such a system.  Also, pointers
to relevant back-issues of RISKS will be appreciated.

Thanks, DL



### Re: Ada Code Formatters (... old software) (Mitchell, RISKS-12.45)

David Parnas <parnas@qusunt.Eng.McMaster.CA>
Wed, 9 Oct 91 16:06:57 EDT
Kent Mitchell <KDM@rational.com> indicates that a bug in his company's products
has been corrected and that it is no longer a problem.  He then goes on to say,
"Perhaps the real risk here is using old, out of date software."  Others might
say, "Perhaps the real risk here is prematurely released software, software
that is released before adequate validation".  How long can we go on acting as
if it is OK to release buggy software as long as we fix it (for an extra charge
of course) later.
David L. Parnas           parnas@sscvax.cis.mcmaster.ca



### Re: Encryption Exportability, by Clark Weissman (RISKS-12.46)

Carl Ellison <cme@ellisun.sw.stratus.com>
Thu, 10 Oct 91 14:28:52 EDT
>The U.S. finds itself in a dilemma: harm our economic growth and
competitiveness in the expanding world internet products and services
industries if we prohibit cryptographic applications, or permit such
cryptographic export and potentially weaken military security by providing
new encryption capabilities to our adversaries.

I have heard this argument multiple times and I find it bogus.

This argument assumes that we in the US are in a leadership position
in the development of encryption products so that if we ship products,
our adversaries will get something they can't get elsewhere.

It's doubtful that this has ever been true, except possibly for the top of the
line NSA black boxes -- but that's not what we're talking about controlling,
here.  We're talking about the products of US private industries.  Crypto AG in
Switzerland isn't waiting for the US to permit exports.  They have been
producing high quality equipment for decades and will continue to do so.  Other
companies are starting up to produce and sell cryptographic equipment.

Therefore, to me there is only one side to this argument: if we prohibit
export, we limit the US competitiveness, while our adversaries get equipment
and algorithms at least as good as they might buy indirectly from us, but from
other countries.  Meanwhile, the thwarting of US industrial development of
cryptographic applications and equipment leads to an atrophy of ability in US
industries so that even we will have to buy equipment from outside this
country.

The last time I looked at smart card cryptography, it was all produced in
Europe, for example.

Is this going to be another case of the USA losing out completely on a market
-- ala VCRs?

My guess is that it already is -- thanks to at least a decade of restrictions.
My remaining question is whether we have any chance to catch up, assuming we do
a rapid and firm about-face in policy immediately.



### Re: Fiber optics can spontaneously destroy themselves! (RISKS-12.44)

Paul Leyland <pcl@oxford.ac.uk>
Thu, 10 Oct 91 10:51:18 +0100
> It turns out that a fiber optic in an environment "where the temperature
can suddenly increase" can result in the complete destruction of a fiber
optic in what is known as a fiber "fuse" effect.  "For certain types of
optical fibers...damage can occur when the visible-light laser power
transmitted... is as low as 4 milliwatts..."

I'm surprised that a power of 4mW can destroy a fibre.  Ten years ago, I was a
practising spectroscopist.  Several times I saw a fibre melting away in an
upstream direction.  The output end of the fibre had become dirty and absorbed
the laser light; the fibre's tip melted, ensuring that light continued to be
absorbed.

The big difference, though, was that we were pumping anything up to 10 WATTS
through a 150 micron fibre.  Admittedly, this was 514.5nm Ar+ light, rather
than the red and near IR used in telecommunications, but as glass is more
opaque in the green than near IR, I'd expect greater problems with Ar+.  I
*never* saw a fibre burning away when less than several watts were being
transmitted.

If we calculate the power densities involved, 10 watts through 150\mu is a
power density of 566MW m-2; 4mW through the same fibre is 226kW m-2.  For
comparison purposes, a typical electric fire element (in this country at least)
radiates 1kW from an area of 0.01 m-2 (assuming a length of 30cm and a diameter
of 1cm) for a power density of 100kW m-2.  It glows dull red-orange.

Hmm, I suppose that 200kW m-2 might melt a fibre if the laser light were
converted to heat with high efficiency.
Paul



### Re: Safer flying through fly-by-wire (Spencer, RISKS-12.45)

Randal L. Schwartz <merlyn@iwarp.intel.com>
Thu, 10 Oct 91 09:39:28 PDT
> The USAF/NASA Advanced Fighter Technology Integration test aircraft is doing
flight evaluations of a system to help pilots cope with disorientation: push a
button on the stick and the computer automatically brings the aircraft back to
level flight.

But level flight based on what indications?  Every IFR pilot is taught to
"right" herself based on the array of gauges visible on the panel, and must do
so with demonstrable proficiency before being signed off to "bore holes in the
clouds".  But we are also taught to cross-check...  does the Artificial Horizon
"make sense" compared to the changes in Altimeter and Heading?  Does the
Rate-of-turn indicator cross-check with that?

I can't see how this device is better than your basically-trained IFR pilot,
and it may be worse (mortal failures under strange instrument failure modes).

Randal L. Schwartz, PP-ASEL-IA, 260+ hours and climbing...



### Re: Friendly'' (?) viruses (Smee, RISKS-12.45)

Bertrand Meyer @ Interactive Software Engineering Inc. <bertrand@eiffel.com>
Thu, 10 Oct 91 12:35:23 PDT
     It is an (at least) antisocial act to cause anything to run
on my machine without my knowledge, and with no action on my part
to indicate that I want it. I cannot think of ANY useful piece of
software of ANY sort [...] which does not have the potential for
screwing things up amazingly in SOME contexts.''

Although I see no reason to disagree in principle, it may be worth pointing out
that this statement, taken literally, is too strong to reflect the reality of
even the most common computer systems, which DO execute things without explicit
actions from their owners and users.

Most people reading this use a machine running Unix. Somewhere in its file
system (usually /usr/spool/cron or /var/spool/cron) there is a directory
crontabs' containing files which describe actions to be executed regularly
without explicit user action. In particular, the file root' describes actions
to be executed by the root' id, that is to say, with all possible privileges.

Such mechanisms, if used well, are essential to the proper functioning of the
system. For example some typical cron' actions remove unneeded or old files.
For one thing, news wouldn't work without cron, since the flow of incoming
messages would quickly fill out all available disk space. Neither would mail
work without the help of some programs, running automatically (the Unix name,
daemon'', is suggestive enough), which do a few things on their own, such as
checking the incoming mail queue every now and then.

One may argue that there is implicit action on the owner's part'', using Mr.
Smee's words: by accepting to use the machine, you accept its standard cron
mechanisms and mail daemons; furthermore, you may login as root' and disable
the daemons and cron actions that you don't like.

But most people probably just leave the software as it was when the machine was
installed, and as Unix reaches the masses there will be more and more users who
don't even know about the existence of cron and daemons. So in effect the
operating system IS performing, behind the user's back, actions which may
directly affect his property (files, electronic mail etc.).

It's a little like signing an agreement letting a supplier or employer make
direct drafts from your bank account: sure, you did perform one explicit
action'' when you authorized it, but it still opens more risks than if you have
to authorize each operation individually.

So while I agree with Mr. Smee and other posters about the oxymoronic nature of
friendly virus'', I think the technical situation is a little more complex
than his statement would suggest.

It also seems that an automatic or semi-automatic bug correction service,
working somewhat in the style of mail and news (that is to say, updating remote
files in controlled conditions) wouldn't be such an absurdity as he suggests. I
can see why some user sites might want to subscribe (voluntarily, of course!)
to such a service if it is technically well-done and has the proper safeguards.
(Maybe something like that already exists.) After all, those of us who can read
this still use mail and news in spite of the Internet worm and of the potential
for further abuses of the same kind.
Bertrand Meyer      bertrand@eiffel.com



### AT&T Outages

"Peter G. Rose" <LCO114@URIACC.URI.EDU>
Wed, 09 Oct 91 15:52:32 EDT
Some people seem to want to blame human weaknesses for the AT&T failure, other
people seem to want to blame the technology.  What I havan't seen anyone point
out is that, every time AT&T (or most other people) does something to "improve"
their system, they end up more and more centralized.

Fundamental rule of designing things:
"Sooner or later, EVERYTHING breaks."

If you don't what catastrophic failures, you need to arrange things so that the
inevitable failures aren't catastrophic.  Why is so much vital traffic being
routed through a single installation?  What are they planning to to when a
fire, plane crash, flood, or terrorist action takes out that entire building?
Why is the control network dependant solely on AT&T, when anyone with any sense
could predict that sooner or later, that service isn't going to be there?

P.Rose (LCO114@URIACC.URI.EDU)



### Re: RISKS of Highway warning signs (RISKS-12.45)

Steven Philipson <stevenp@kodak.pa.dec.com>
Wed, 9 Oct 91 14:29:12 -0700
   Several persons commented that the cause of the accident was not that the
signs were not working, but rather that the truck driver was not paying
attention.  The inattentiveness of the driver may have been the most
significant factor, but the failure of the signs is also significant.  The
driver may have had an expectation that the warning signs were operating.  Lack
of the warning contributes to lower attentiveness.

This phenomenon has a name -- primary/backup inversion.  The driver should
have been more attentive, but warning systems do tend to make people less
attentive.  Designers must keep this in mind when developing warning and backup
systems.

This accident clearly falls in the category of a "system accident" --
multiple factors in a complex system (including surface traffic, river traffic,
drawbridges, warning systems, rules of operation, working hours) collectively
contributed to the outcome.  Charles Perrow's _Normal Accidents_ discusses
system accidents in detail.  It is well worth reading.
Steve Philipson



### Re: RISKS of Highway warning signs (Flory, RISKS-12.45)

Arthur Hamlin <hamlin@codex.com>
Thu, 10 Oct 91 10:41:25 EDT
>The was no risk here because the signs weren't working.  The risk was the truck
driver obviously driving recklessly.  There's too much of a tendency to blame
something or someone else when things happen.  Bottom line is, if the trucker
had been driving safely, the accident WOULD NOT HAVE HAPPENED, sign or no sign.

Unless you have additional information about the accident, I must disagree.  If
I am on an unfamiliar highway, it is up to the maintainers of the highway to
"tell" me how to drive it safely. This includes speed limits, warnings about

There is a section of a Rt 9 in Mass. that has a stop light just over the top
of a hill. You can't see it as you come up the hill, but only as you come over
the top.  The speed limit on this road is 45mph, far too fast to react to one
or more stopped cars at a red light.  The town put up a permanent sign clearly
stating that there was a stop light over the hill and that cars may be stopped
at it. This warning has worked very well.

However, several miles down the road, in a different town, they use an electronic
sign that only turns on when the light is RED. The idea being that if the light is
green and there are no cars backed up, there is no danger, so no need to slow down.
Assuming that the sign goes on and off correctly, ( including time delays after
cycling to allow a backup to disperse ) this will work fine. But as soon as the
electronic board fails, THERE IS NO WARNING. A driver not knowing the road would
go 45mph, ( the posted "safe" speed ) having no reason to think that there is any
problems ahead, and smash into the cars backed up at the red light. A driver who
knows the road would assume that the sign would warn him if there was a backup,
so he too would be in danger. ( I'll grant you that this driver should be going
a little slower over the hill because he knows that there is a potential problem )

If all drivers drove as if they had to be able to stop on a dime at all times,
cars could not be a pratical form of transportation. Drivers rely upon the
maintainers of the highways to tell them what the risk level of the road they
driving is, so that they can then drive "safely".
The Wizard of AHs

P.S. Some places use a permanent painted sign that warns of the danger all the
time, and the electronic lighted sign obscures it when it is on.  Therefore, in
the case of failure, the warning is up. Sort of like four way stop signs at an
intersection with lights.



### RE: Liability risks of highway signs

Richard Thomsen <rgt@beta.lanl.gov>
Thu, 10 Oct 91 08:29:09 -0600
My uncle, who was a law lecturer at Cambridge, England, was telling me about
liability risks.  He said that sometimes if you put up a warning sign, then you
are admitting that there is a hazzard, and so you are liable.  However, if you
say nothing, then you are not liable.  Interesting cases.
Richard Thomsen



### Re: RISKS of Highway warning signs (Hoffman, RISKS-12.44)

Bob Haar <rhaar@gmr.com>
9 Oct 91 21:07:53 GMT
Certainly, there are risks associated with the expectation that any warning
devices will really function. But I have to lay blame for this accident on the
truck driver. Whether or not the signs were operating with appropriate
messages, the driver of any vehicle is responsible for operating it in a
"reasonably safe" manner. This includes being able to stop the vehicle if there
is an obstruction in the road.

In this case, either the truck driver was not paying attention or he was
driving too fast so that he couldn't stop when he did see the stopped traffic.

There are many possible causes for an obstruction in the road that have nothing
to do with the drawbridge. The warning signs would not have given notice of
these.
Robert Haar, Computer Science Dept., G.M. Research Laboratories



### Warning systems

<hkhenson@cup.portal.com>
Thu, 10 Oct 91 17:29:35 PDT
While it would not have helped any on the recent ATT outage, a serious problem
is trying to use people to backup machines--they get bored and nod off.
Perhaps we need to have on purpose, unpredictable "false alarms" for people to
respond to.  I could eaisly design such a device to give a false warning at the
sensor leads once a month or so.  You could make pay, or rewards, or something
dependent on taking corrective action, starting with reseting the signal.  You
might want an short term inhibit signal so that test alarms wouldn't pop up
during a real emergency.  Let's see, I have a year from this going out to file
for a patent.  :) Keith Henson

[Well, this idea keeps coming up in RISKS, every time we
have a problem with backup and emergency systems...  PGN]

`

Please report problems with the web pages to the maintainer

Top