The Risks Digest

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 18 Issue 35

Monday 19 August 1996

Contents

o Justice's Web Site Is Infiltrated
Edupage
o "Vandalized" nuclear controls - Florida
Howard Goldstein
o The risk of plagiarism with Websites (Roy Dictus) Names of punctuation as a risk
Jeremy J Epstein
o Inability to "take it apart and see how it works"
Daniel P. B. Smith
o Reliance on e-mail in an emergency
Ramon L. Tate
o The Atlanta 911 transcript
PGN
o Buggy metaphors
William Ehrich
o How telcos upgrade switches
R. Spainhower
o Rebooting vs. 7x24 Operations
Jeremy Leader
o Re: Upgrade Hell
Henry G. Baker
o Measuring time-to-fix
David Holland
o Alternatives to Social Security Numbers
Robert Ellis Smith
o Re: Department of Motor Vehicle records
Jan Vorbrueggen
o Re: California DMV records NOT secure
A.E. Siegman
o Info on RISKS (comp.risks)

Justice's Web Site Is Infiltrated (Edupage, 18 August 1996)

Edupage Editors <educom@elanor.oit.unc.edu>
Sun, 18 Aug 1996 16:12:13 -0400 (EDT)
The U.S. Justice Dept.'s Web site < http://www.usdoj.gov/ > took on a quite
different look after crackers broke in this weekend and altered the page to
include swastikas, obscene pictures and criticism of the Communications
Decency Act.  The site was shut down following the discovery Saturday
morning; the department expects to reconstruct the page and have it running
again by Monday, if not before.  (*St. Petersburg Times*, 18 Aug 1996, A12)


"Vandalized" nuclear controls - Florida

Howard Goldstein <hgoldste@mpcs.com>
17 Aug 1996 18:18:30 GMT
The FBI pulled out of an investigation concerning glued switches discovered
in a backup control room at FPL's Hutchinson Island (near Ft Pierce,
Florida) nuclear facility, so reports the AP in an item carried in 16
August's _Florida Today_.

A security alert was issued Wednesday when glue was discovered in three
locked switches in the backup control room, a facility used in case the
primary control room is unusable.  An FBI spokesman is quoted as justifying
pulling out of the investigation because the FBI lacked "jurisdiction...it
really came down to an act of vandalism or tampering."

The piece fails to mention the plant features that would have been affected
by the glued switches.

Investigation is reportedly focused on employees.  The article implies
a link between the vandalism and complaints about a November round of
job cuts at the facility.


The risk of plagiarism with Websites

"Roy Dictus, NET" <roy@net.be>
Wed, 14 Aug 1996 00:03:42 +0200
My company recently got ripped off by a competitor.  We build Websites and
thus had constructed a site detailing our products and services.

A rival Website constructor (!) copied practically the entire site,
changing the background color, changing our name into theirs, and making
other slight changes like alignment, add and delete a word or phrase
here and there...

I complained about it, not only to them directly, but also on a local
USENET newsgroup (we're both located in Belgium, so the newsgroup was
be.providers).

On the phone they just laughed at me and admitted to copying, but on
USENET they claimed I had copied their site!

There's nothing I can do to prove them wrong, even though we both know
what happened.

The risk: if you put your materials on the Internet, where they can be
freely copied, make sure you have some way to prove you made them yourself,
and when you did it.

Roy Dictus, NET bvba, Internet Projects & Consulting
roy@net.be  http://www.net.be

  [Interdictus becomes Enter Dictus.  PGN]


Names of punctuation as a risk

JEREMY J EPSTEIN <JEPSTEIN@cordant.com>
Fri, 16 Aug 1996 16:21:37 -0500
My sister in Israel recently joined the Internet.  She had a certain amount
of trouble getting her PC configured correctly to hook to the service
provider, in part because (I'm told) the name of the semicolon in Hebrew is
(translated) "period comma".  So when she was told over the phone to put in
a "period comma" in a configuration file, she did that (.,) rather than the
required semicolon (;).  Needless to say, the software didn't find the two
interchangeable.

I think the risk is that we computer-types assume that everyone will
understand the ambiguous meaning of terms.  The fact that this happened to
be in another language just makes the point a bit clearer.


Inability to "take it apart and see how it works"

"Daniel P. B. Smith" <dpbsmith@world.std.com>
Sat, 17 Aug 1996 16:28:09 -0400 (EDT)
When my father was nine, his Uncle Will, who was fond of practical jokes,
gave him a magnetic compass--and said "Why don't you take it apart and see
how it works?"

Technical education rests on intuitive understanding gained through
unsupervised, unstructured exploration in childhood. Before I went to MIT,
I was crushing vacuum tubes in vises, and connecting automobile spark
coils to a big antenna to see whether my friend with the shortwave radio
could pick up the resulting RFI.  [...]

Thirty years ago, a lot of our technology was accessible to direct
exploration.  You could "take it apart to see how it works." You could see
the grooves in a phonograph record, put it under a microscope and see the
wiggles, and experiment by putting fingernails or sharp objects into the
grooves.  You could smash a vacuum tube and see the little grid wire inside
it.  You could overload a vacuum tube and see the anode get red hot.  (My
real learning took place in the basement, not the science fair).

What is the effect on our society as more and more of our technology
vanishes inside the chip?  The behavior of engineered objects depends less
and less on physical and mechanical relationships, and more and more on
arbitrary behavior designed into firmware.  I fear that the engineers of the
future will lack a certain kind of gut intuition that comes from direct
tactile contact with "the works."  We know what is being gained, but are we
sure we know what is being lost?

Daniel P. B. Smith dpbsmith@world.std.com


Reliance on e-mail in an emergency

Ramon L. Tate <rtate@helix.nih.gov>
Mon, 19 Aug 1996 11:07:42 -0400
As did many organizations, the National Institutes of Health received
several bomb threats on Monday, July 29, in the wake of the bombing in
Atlanta, GA. Several buildings were evacuated and searched but no bombs were
found. While the NIH campus is extensively networked, the use of e-mail as a
general nofication mechanism was found to be wanting:

[excerpted from a memo from the NIH Director]
  "In addition to notification of all staff through usual administrative
  channels, an attempt was made soon after the threats were received to
  utilize our e-mail system to inform all NIH staff of the threats. The
  delivery of this notification was delayed in many cases because an
  equipment failure over the weekend created a backlog of messages on Monday
  morning  and because our current list-serv system was unable to deliver
  24,000 messages in a timely fashion."

This incident serves to underline the oft-stated (and oft-ignored) risk in
relying on systems that were (a) not designed to do the job required of them
and (b) never subjected to realistic testing to see if they *could* do it
anyway.

Ramon L. Tate, Ph.D., National Institutes of Health, Bldg.14A, Rm. A116
Bethesda, MD 20892-5515  rt3e@nih.gov


The Atlanta 911 transcript

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 16 Aug 96 10:45:34 PDT
  [The following transcript of the Olympic 911 bomb call and the ensuing
  conversation suggests that many of our nontechnological risks are not
  being adequately addressed.  PGN]

http://www.cnn.com/US/9608/09/olympics.bomb.911/911.transcript.wir/transcript.html

Excerpts from a transcript released Thursday by the Atlanta Police
Department regarding the bomb threat telephoned to 911 on July 27. Times
have been converted from military time to standard notation, and punctuation
and spelling have been edited.  Parenthetical notes are part of the police
transcript except where labeled as an editor's note.

The transcript refers to these police terms: Code 73, bomb threat; and
Zone 5, a police precinct near Centennial Olympic Park.

The transcript did not explain the Zone 5 dispatcher's references to Code
17 and Code 8, which apparently were unrelated to the bomb call.

12:58:28 a.m.:  [Call to 911]

12:58:32 a.m.:  Atlanta Police Department 911 Operator: "Atlanta 911."
Caller:         "There is a bomb in Centennial Park, you have 30 minutes."
12:58:45 a.m.:  Caller hangs up.

1:01:20 a.m.:   911 operator calls APD Agency Command Center (all lines busy).
....

1:01:30 a.m.:   911 operator calls Zone 5 and notifies Zone 5 of Signal 73 and
                requests address of Centennial Park -- unable to get street
        address.

Dispatcher:     "Zone 5."
911 Operator:   "You know the address to Centennial Olympic Park?"
Dispatcher:     "Girl, don't ask me to lie to you."
911 Operator:   "I tried to call ACC but ain't nobody answering the phone ...
                but I just got this man called talking about there's a
                bomb set to go off in 30 minutes in Centennial Park."
Dispatcher:     "Oh Lord, child. One minute, one minute. I copy Code 17. OK,
                all DUI units are Code 8 and will not be able to
                assist on the freeway.
                Oh Lord, child. Uh, OK, wait a minute, Centennial
                Park, you put it in and it won't go in?"
911 Operator:   "No, unless I'm spelling Centennial wrong. How are we spelling
                Centennial?"
Dispatcher:     "C-E-N-T-E-N-N-I -- how do you spell Centennial?"
911 Operator:   "I'm spelling it right, it ain't taking."
Dispatcher:     "Yeah."
911 Operator:   "Centennial Park is not going. Maybe if I take 'park' out,
        maybe that will take. Let me try that."
Dispatcher:     "Wait a minute, that's the regular Olympic Stadium right?"
911 Operator:   "Olympic Stadium is like Zone 3, though. Centennial Park."
Dispatcher:     "That's the Centennial Park?"
911 Operator:   "It's near the Coca Cola Plaza, I think."
Dispatcher:     "In 5?"
911 Operator:   "Uh huh."
Dispatcher:     "Uh, hold on. Sonya, you don't know the address to the
        Centennial Park?"
2nd Dispatcher (in background): "Downtown."
911 Operator:   "Male, about 30."
Dispatcher:     "1546, Code 17, 23."
911 Operator:   "White."
Dispatcher:     "Uh, you know what? Ask one of the supervisors."
911 Operator:   "No, Lord help me, you know they don't know."
Dispatcher:     "I know, but it gets it off you."
911 Operator:   "Alrighty then, bye."
Dispatcher:     "Bye."

1:02:40 a.m.:   911 operator calls APD ACC for address (telephone line problem;
                operators cannot hear each other.) ...

1:02:50 a.m.:   911 operator calls APD ACC again and requests address for
                Centennial Park and is given the telephone number.

ACC:            "Atlanta Police, Agency Command Center."
911 Operator:   "Hey, can you hear me now?"
ACC:            "Uh huh."
911 Operator:   "OK, can you give me the address of the Centennial Park?"
ACC:            "I ain't got no address to Centennial Park, what y'all
        think I am?"
911 Operator:   "Can you help me find the address to Centennial Park?"
ACC:            "I can give you the telephone number of Centennial Park."
911 Operator:   "I need to get this bomb threat over there to y'all."
ACC:            "Well."
911 Operator:   "But I need the address of Centennial Park. It's not taking,
                the system is not taking Centennial Park, that's not
                where it came from, but you know the system is not
                taking Centennial Park, that's where he said the bomb was."
ACC:            "No particular street or what?"
911 Operator:   "He just said there's a bomb set to go off in 30 minutes in
                Centennial Park."
ACC:            "Ooh, it's going to be gone off by the time we find the
        address."
911 Operator:   "Are you kiddin'? Give me that, give me that."
ACC:            "I mean I don't have an address, I just have phone
                numbers."
911 Operator:   "Give me the phone number."
   ...

1:05:10 a.m.:   911 operator calls Centennial Park for street address and
        is placed on hold. Receives address at 1:07:10 a.m.

Centennial Park: "Centennial Park, this is Operator Morgan."
911 Operator:   "Hi, can you give me the address to Centennial Park?"
Cen Park:       "The address?"
911 Operator:   "Uh huh."
Cen Park:       "Uh, hold on a second."

1:06:30 a.m.:   911 operator notifies Communications Supervisor, Sgt.
        Montgomery.

911 Operator:   "Does anybody -- Sgt. Montgomery, do you know the address of
                Centennial Park? Do you know the address to Centennial Park.
                Well, I need to get the address of Centennial Park 'cause, I
                mean I don't mean to upset nobody, but we got a bomb threat
                over there."

(Editor's note: The transcript does not further indicate whether this
comment about a bomb threat was directed only to Sgt. Montgomery in the
911 center or to Centennial Park's Operator Morgan, who is shown to come
back on the line just after the comment.)

Cen Park:       "Ma'am."
911 Operator:   "Yes."
Cen Park:       "OK, it's 145 International Boulevard."
911 Operator:   "145 International Boulevard."
Cen Park:       "Uh huh."
911 Operator:   "OK."
Cen Park:       "All right, uh huh."
911 Operator:   "Thank you. Bye bye."

1:08:35 a.m.:   911 operator sent call to dispatch.

1:11:10 a.m.:
Dispatcher:     "1591. Radio raising 1594."
Unit 1594:      "1594. You call?"

1:11:20 a.m.:
Dispatcher:     "1594, that's affirmative, got a Signal 73 at 145
        International Boulevard. It came from the pay phone at
        the Days Inn.  The caller is advising that he has one set
        to go off in 30 minutes at Centennial Park. Sounded like
        a white male."

(Editor's note: The same information is then given to Unit 1593 and the
dispatcher calls Unit1546.)

1:12:30 a.m.:
Dispatcher:     "Did you copy?"

1:12:40 a.m.:
Unit 1546:      "1546. I copy. Advise the state police, they police that park.
                I'll go the Days Inn and see if I can locate the caller."
Dispatcher:     "OK, that's affirmative."


(Editor's note: There are sporadic entries over the next seven minutes.
Another officer,  designated Unit 1593, also instructs the dispatcher at
1:18:50 a.m. to "contact the state police supervisor." The transcript
contains no indication, however, that state police were notified.)

1:20:00 a.m.:
Unit 2924:      "2924 to Radio, be advised that something just blew up at
                Olympic Park."


Buggy metaphors (Gilbert, RISKS-18.34)

William Ehrich <ehrich@minn.net>
Sun, 18 Aug 1996 09:32:16 -0600
Lowell Gilbert wrote in RISKS 18.34:

> The metaphor of hardware design ... is so weak as to be downright disingenuous.

A better metaphor might be crime. It is hard for a detective to predict
accurately how long it will take to find out who committed a crime. It is
equally hard to prevent future crimes. And we've been trying to solve those
problems for much longer than we have been debugging software.

- Bill E


How telcos upgrade switches (Kletnieks, RISKS 18.34)

<rs@world.std.com>
Mon, 19 Aug 1996 10:45:48 -0400
Bruce Sterling provides a very interesting summary of how the telephone
companies take care of software upgrades to switching systems in his book
_The Hacker Crackdown_.

The basic process is this: start with all of the switching stations with the
old software.  Outfit one station with the new software.  Watch it run for a
while and see what happens.  If it's broken, only a few (!)  people will be
out of phone power.  When it seems like it's working OK, add another
station.  When that one seems like it's working, add another station.  And
so on until all of the switches are outfitted with the new software.

The legendary Crash of 1990 happened when AT&T had approximately 75%
of stations outfitted with new software, and the bug that caused the
crash could only cause a crash when a critical mass of stations had
the new software (and the new bug).

R. Spainhower                         rs@world.std.com


Rebooting vs. 7x24 Operations

Jeremy Leader <jeremy@worlds.net>
Fri, 16 Aug 1996 13:44:18 -0700
The recent discussion of seamless upgrades, and the idea that telephone
switches might never have been "booted" to begin with (having been
seamlessly upgraded over the years from their original mechanical
incarnations) reminded me of a similar situation.

This was when I worked for a large mainframe manufacturer (the adjective
applies to both the company and their products) in the mid-1980s.  I was
working with the folks who wrote the operating systems for these mainframes,
and we had roughly half a dozen machines used by various software
development projects (OS, compilers, databases, tools, etc.).  Many of these
machines were running early beta test versions of the operating system.
These machines could either be "cold booted", where a fresh operating system
image was loaded from tape to disk and various data structures on the disk
re-initialized, or "warm booted", where the current operating system image
was used, with the data structures as they were when the machine was
stopped.  Patches could be (and frequently were) applied to the operating
system image on disk, followed by a warm boot.

It turned out that no one was cold-booting the machines, because it took too
much time and effort.  It was discovered that some machines hadn't been
cold-booted for many months!  Typically, in that time, dozens of patches had
been installed, some of which might affect the cold-boot process.
Management announced that all machines would henceforth be cold-booted
weekly, to verify that they still could be.

The risk of a system that almost never needs to be taken down is that when
it does need to be taken down, it might be hard to bring it back up!  Or,
practice makes perfect?

Jeremy Leader  Tujunga, CA, USA  jleader@alumni.caltech.edu
<http://www.alumni.caltech.edu/~jleader/>


Re: Upgrade Hell (Nuri, RISKS-18.33)

Henry G. Baker <hbaker@netcom.com>
Sat, 17 Aug 1996 09:17:04 -0700 (PDT)
1.  Upgrading a program is usually pretty easy -- the hard part is upgrading
the database it operates on.  It's amazing that 'program development
environments' spend all this effort on the program portion, and virtually
none on the database portion.  Common Lisp Object System (CLOS) is one of
the few systems that actually provides a smooth 'upgrade' mechanism in which
multiple versions of objects can simultaneously coexist, along with a 'lazy
upgrade' ability -- older objects can be automatically upgraded 'on sight'.

2.  Without rehashing all of the arguments for/against N-version again, I
just want to point out a few key ones against.  There are occasions where
_any_ decision is better than _no_ decision -- e.g., which side of an
obstacle to detour around; it usually doesn't matter, but you are guaranteed
to crash if you don't choose one.  Apparently, at least one crash (or
near-crash) of an experimental, statically-unstable NASA airplane occurred
when two different systems proposed two different answers, and the
supervisor system concluded that both subsystems must have malfunctioned,
thus causing the big red light on the pilot's console to come on ("total
computer system malfunction") (heresay from a conference lunch
conversation).  Another problem from the multiple language N-version efforts
(C/Fortran/Ada): a _good_ answer from -- e.g. -- the Ada implementation can
be outvoted by a _bad_ answer from -- e.g. -- the C and Fortran
implementations.

Henry Baker  ftp.netcom.com:/pub/hb/hbaker/home.html


Measuring time-to-fix (Mellor, America Offline, RISKS-18.33))

David Holland <dholland@hcs.harvard.edu>
Mon, 19 Aug 1996 20:43:13 -0400 (EDT)
Several people have made the point that you can't classify bugs in advance
of fixing them and therefore can't make much in the way of useful
predictions of how long it will take to fix them.

This is quite true (although some very vague generalizations can be made.)

It would be more interesting, however, to measure the time it takes to fix
bugs in particular programs. Some programs are better designed than others.
Some of the time this translates into some programs being more debuggable
than others. (And sometimes it doesn't.) There are thousands of other
factors involved, but I suspect most of them are reasonably uniform for the
lifetime of a single project at a single company.

Thus you might be able to make some vague predictions for the time it takes
for the average bug in a specific program (well, code base, probably) to be
fixed.

Admittedly this is not especially useful for telephone companies and the
like, but it might work for an operating systems vendor. Or for customers
choosing software, if vendors could be convinced to disclose the data.

One would have to get some actual data to see if any statistically useful
conclusions can be drawn.

David A. Holland  dholland@hcs.harvard.edu


Alternatives to Social Security Numbers

Robert Ellis Smith <0005101719@mcimail.com>
Fri, 16 Aug 96 15:24 EST
Last spring, I asked readers of RISKS for suggestions on alternatives to
Social Security numbers in organizations with large data bases of
information about individuals.  Many such organizations find they do not
need to use SSNs, and avoid privacy problems associated with using them.
For a copy of all of the responses, send a request to us and specify whether
you want hard copy or electronic edition of our August issue, and provide
postal address or e-mail address.

Robert Ellis Smith, Publisher, Privacy Journal newsletter,
Providence, RI, 401/274-7861, e-mail 5101719@mcimail.com.

Excerpts from the suggestions follow:

* FROM WASHINGTON, D.C.: Maryland uses Soundex (of name and birth date
concatenated [linked in a chain]) both for driver and vehicle registrations.

* FROM CAMBRIDGE, MASS.: "Against Universal Health-Care Identifiers" in the
JOURNAL OF THE AMERICAN MEDICAL INFORMATICS ASSOCIATION 1:316-319, 1994, by
Dr. Peter Szolovits of MIT and Dr. Isaac Kohane of Children's Hospital in
Boston, discusses a number of ways in which cryptography- based health care
identifiers can be used to preserve privacy while remaining manageable for
typical medical purposes.  This is publication #49 (in Postscript format) at
http://medg.lcs.mit.edu/people/psz/publications.html.

* FROM YARDLEY, PA.: One way is to use a simple scheme like three letters
from last name, the first initial, and some digits; another is just to use
sequential numbers.  Another is an MD5 hash of the full-name string [a
one-way mathematical function as a stand-in for the name that makes
translation back to the original name impossible].  This is always unique
for a unique string, so you might need to add some numbers.

* FROM MADISON, WISC.: When I was working on the development of the
Wisconsin Student Data Handbook - we tried to develop
 what we called an "SSN surrogate," also of nine bytes per
individual.  It involved an algorithm which combined year,
month, and date of birth with sex and two consonants each
 extracted from the first and middle names.

* FROM CYBERSPACE: I worked with a banking software company that set up
employee records simply by exact hire date and time.  Since they never hired
anyone at exactly the same time, it gave each person a unique number.  You
could do the same for any data base in which records are added gradually one
at a time - just number them based on exact date and time added.

* FROM PALO ALTO, CAL.: At Stanford University we made a decision long ago
not to use SSN for identification except where required by law (payroll
taxes, for example).  We use a unique Stanford University ID (SUID), which
is a lifetime number and applies to all students, alumni, faculty, staff,
and patients.  It serves all the same purposes that the SSN would do if it
were used.


Re: Department of Motor Vehicle records (Johnsrude, RISKS-18.31)

Jan Vorbrueggen <jan@fsnif.neuroinformatik.ruhr-uni-bochum.de>
Mon, 19 Aug 1996 13:12:06 +0200
Johnsrude writes:

>   This lack of protection distinguishes American law from most European
>   democracies.  "Data protection" is an important part of European human
>   rights law.

A very important point. In Germany, this was actually derived, in the
context of a census, from the constitutional right to freedom from injury by
the Bundesverfassungsgericht (sort-of-analogue of the US Supreme Court). The
laws that were made in response to this decision actually strive to handle
the problem at the correct point, IMO, namely when the data in question is
created.  And there is a distributed system of "watch dogs" whose annual
reports are widely discussed (if not always read).

However, I think the bulk of Johnsrude's contribution and the further
discussion in this thread misses a major point. The DMV database is quite
different from, say, VISA's or your favourite retailer's, in that the DMV
occupies a monopoly, and a publicly mandated one at that. If you don't like
the data handling procedures of whoever offers you a service, in general
there will be a competitor who might have better practices regarding your
objections.  Or you can make a purchase explicitly contingent on data
concerning it not being made available to others, and in the case of
infraction sue for breach of contract (of course, this entails other barrels
of worms, but that's a separate discussion). In the case of the DMV, there
is no alternative, because the DMV itself, as an issuer of drivers'
licenses, serves a public watchdog function, and the service it offers is
not in any practical sense optional, especially in wide parts of the United
States. Putting severe restrictions on the DMV's use of the data entrusted
to it is sensible, for any number of reasons; the technical problems in
distributing data to those that need to know (e.g., police officers) come up
in other situations as well and have well known solutions.

One of the root problems here is that, IMHO, the way legislative
responsibility has been divided in the USA is just crazy. The (I assume)
federally mandated inclusion of the SSN in state controlled DMV records,
without any clauses on how to protect this data, is a case in point; I
suppose this was foisted on the states in a similar way the drunk driving
rules were (according to urban legend, by making federal subsidies for the
interstates contingent on such legislation). Thus, responsibility is divided
- in a similar way later noted as being the result of the privatization of
the British rail network.

        Jan


Re: California DMV records NOT secure (Seecof, RISKS-18.3x)

AES <siegman@ee.stanford.edu>
Fri, 16 Aug 1996 15:52:22 -0700
Not to hammer this point, but if DMV records are going to be readily and
speedily available to law enforcement agencies at the lowest level, e.g.,
deputy sheriffs and dispatchers in the smallest communities, as seems
necessary to me for rational police work, then as a practical matter these
records are not secure at all, at least not to any intruder with a modicum
of intelligence..

The RISK of thinking that DMV records are secure when in fact they're not
then seems worse to me than the benefits, if any, of thinking they are
secure.

Please report problems with the web pages to the maintainer

Top