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 14 Issue 13

Weds 2 December 1992

Contents

o Blackmail risk in thefts from general practitioners
Paul Leyland
o Computerized Voting
Doug Hardie
o Global Positioning System - Position Errors
Stuart Bell
o Re: Laser Printer Sucks up Cat
Dan Sorenson
o Smokey is not always a bear
Alan Dahl
o A310 Aerobatics
Karl Swartz
o New Distributed Systems Engineering Journal
Morris Sloman
o Info on RISKS (comp.risks)

Blackmail risk in thefts from general practitioners

Paul Leyland <pcl@ox.ac.uk>
Wed, 2 Dec 92 10:50:43 GMT
Blackmail risk from GP thefts (The _Times_ (of London), 2 Dec 1992)

A sharp rise in the theft of computers from doctors' surgeries has led to
increasing numbers of patients' medical records falling into the hands of
burglars and potential blackmailers.

In the past six months, the number of general practitioners seeking advice
from the office of the data protection registrar after the theft of a surgery
computer has risen by nearly 700 per cent.  Officials fear that files could
include information about public figures that buyers of stolen computers might
use maliciously.

The office, based in Wilmslow, Cheshire, has heard of 20 thefts during the
past six months but believes there are many more as holders of personal,
electronically held information are not legally required to report a theft.
Previously there had been about six thefts a year.

The Data Protection Act's eighth principle does, however, require GPs to have
tight security to protect patient records held on computers.  Eric Howe, the
data protection registrar, yesterday warned GPs to review their security.

PCL's comments:

There are a number of interesting observations to be made on this report.
First is the classic scare-statistic fallacy.  A 700% increase sounds
dramatic, and is doubtless significant.  However, an increase from three to
twenty is much less startling.

More important, is the lack of any requirement to notify the authorities of
the theft of equipment containing personal information.  If this is really the
case, it would appear to be a serious loophole in the Data Protection Act.  As
I understand it, the implication is that you are only responsible for the
security of your data until your security measures are broken!

Finally, one must seriously ask: why was the data not encrypted?  I strongly
suspect that the thefts are for the equipment, not the data.  If all data were
DES-encrypted (for example), at the very least it would be protected from the
prying eyes of amateur thieves.  Let me re-phrase that: (possibly)
professional thieves, but amateur cryptanalysts.  I'm prepared to bet a small
sum, at moderate odds, that the database systems that are in common use do not
have easily used encryption, designed for reasonable security but for use by
non-experts in cryptology.

Perhaps a requirement for databases to be used by GPs and the like is the
automatic encryption of all records held on disk.  Only government action
could force such a requirement.


Computerized Voting

Doug Hardie <doug@kronos.nisd.cam.unisys.com>
Wed, 2 Dec 92 10:30:04 PST
During the entire 5 years of undergraduate work at San Jose State, I was a
member of the marching band.  Each year the Band-Aides, a group of 8 or so
young ladies who danced with the band, sponsored one of their members for
homecoming queen.  Each year, that young lady won the election.  I found that
quite interesting since there were only 120 men in the band and a few
additional hanger ons in a 20,000+ person student body.

I also ran the college computer center for the last 3 years and had the
"honor"of opening up the computer center for the committee that counted the
votes for the homecoming queen election.  Each ballot consisted of one
mark-sense card from which one nominee was selected.  The cards were run
through an IBM 519 to convert the pencil mark to one punched hole on the card.
A special program was written, author unknown, to count the votes and
determine the winner.  The entire counting process started about 1800 hours
and ran until about 2200 hours.

The first year I watched this process, one of our journalism students managed
to get one of the San Francisco TV stations to run a live special about this
unusual use of computers.  So the main part of the computer room was filled
with the TV crew and their equipment.  Not wanting to be part of the show, I
retreated to a separate room to the side of the computer that had window
access to see the computer console.  Near the end of the count, while the
journalism student was describing the process live on TV, the computer
"crashed".  I was not able to determine why, but the program was used for
other similar counting tasks without problems.  However, not all was lost.
The operator stated that he had just looked at the counts and knew what they
were.  He would restart the program, restore from memory the counts, and the
counting could continue as if nothing had happened.  A big deal was made about
how a human had saved the day.

About that time I recognized the operator as a fellow band member.  Sure
enough, our candidate won with a resounding margin.


Global Positioning System - Position Errors

Stuart Bell <stu@national.mitre.org>
Tue, 1 Dec 92 08:22:15 EST
Several weeks ago, I completed a 2000+ mile offshore trip to relocate my home,
a 36 foot Pearson sloop, the Shearwater, from Houston, Texas to Washington DC.
Just prior to the trip, I purchased a Magellen Global Positioning System (GPS)
receiver as an aid to navigation.  The Shearwater is already equipped with a
Micrologic Loran, so, in a sense the GPS was a backup - and the Loran was
already a backup to Dead Reckoning - and a sextant.

Somewhere off Port Eads in the Gulf, the GPS began reporting high speeds (70+
knots) and a position far from my current location.  I contacted the Coast
Guard to request a GPS report - and they had no indication of errors.
 After some discussion to assure them that I was in no danger - and knew
where I was, I logged the incident and was about to go back to sleep.
[others were on watch]

Five other boats contacted me to report that they, also, were seeing GPS
position and velocity errors.  I recontacted the Coast Guard to tell them
it was probably not my receiver - although I neglected to ask the others if
they were on different receivers.  They were unable to accept a report and
forward it to GPS control for conformation.

What is the risk?  For a boat using GPS for navigation (that is long-range
position confirmation), the risks are small, especially with sufficient backup
devices).  Since the outage only lasted about 3 hours and I only went about 18
miles during that time, the inconvenience was very minor.  Suppose, however, I
had been piloting - rather than navigating - that is entering a harbor or
avoiding an obstruction with only a small margin of error.  And suppose, also,
I had only one means of navigation and had not maintained an accurate dead
reconing plot - the normal case for most recreational sailors - and apparently
major oil tankers.  Well, this could have been a more serious incident.

Now, suppose I was an aircraft depending on GPS for navigation.  Even if you
don't use it as the sole means of navigation, GPS (or Loran) is so friendly,
so precise, and correct so often that is very easy to fall into the trap of
believing it when it is incorrect.

The risk, I believe, is twofold.  First, the Coast Guard was not aware of the
outage and once informed had no means of informing others or the GPS control
station.  Loran outage reports are accepted, coordinated, rebroadcast and
followed up by the Coast Guard first getting the report.

Second, unlike Loran, my GPS (and the others operated by the folks I spoke
with), reported correct operation, high accuracy, and acceptable performance -
that is good geometric separation.  Thus, if you were flying and were reported
in a place different than you believed, you might believe the report -
especially since it was, in one of the cases, close enough to be believable
under flying speeds/conditions.

I see a problem in the making and don't know who to tell.   /Stu Bell

Stuart Bell, MITRE Corporation, Z646, 7525 Coleshire Drive, McLean, VA 22102
stu@MITRE.ORG   1-703-883-1276   Fax: (703) 883-5519


Re: Laser Printer Sucks up Cat (RISKS-14.12)

Dan Sorenson <viking@iastate.edu>
Tue, 1 Dec 1992 04:41:02 GMT
... It does behoove us, from a safety standpoint, to correct what are known as
"insidious hazards" around the home and office.  Doug mentions the eject
roller on his laser printer.  My own suggestion is to take a plastic car
windshield scraper that has the nylon bristles for removing snow, cut the
handle with the bristles to length, and glue it to the top of the printer
ejection area.  The paper easily pushes under the bristles, but little to
nothing penetrates them when trying to enter that area.  I've done this on my
Imagewriter II when I discovered a curious ferret had lost whiskers when
inspecting the printing head as it whipped back and forth.  Cost?  $1.95 or so
at Kwik Shop.

If you have long hair, such as I, a piece of nylon cut from some ladies
hosiery and taped over the fan exhaust will do little to impede air flow and
does work well to keep hair from being chewed up.  If it is placed on the
input side, it also makes a dandy dust filter.  For those with metal desks or
work benches, did you run a ground strap off the desk before playing with that
flakey monitor?  As my Occupational Safety instructor would pound into us,
"It's the little things that'll get you!"  Luckily, most of these are very
inexpensive and quite simple to fix.  In some companies, such fix suggestions
are worth their weight in gold as they lower insurance premiums and prevent
injury downtime.

To best see just how sly and innocuous these hazards can be, I suggest reading
a book for new parents that goes into detail on how to child-proof the home.
Many of these things apply to offices as well.  Your friendly OSHA
representative, next time he stops by, will also be happy to point out hazards
that might not be covered under OSHA regs.

 Dan Sorenson, DoD #1066 z1dan@exnet.iastate.edu viking@iastate.edu


Smokey is not always a bear

<ctsx!ctsx!alan@uunet.uu.net>
Tue, 1 Dec 92 10:10 PST
The November 30th issue of _AutoWeek_ details the risks of using radar to
prevent bus accidents.

Greyhound has developed a system called VORAD to warn a bus driver if there is
a car hidden off his right or if he's following too closely.  The problem is
the system sends a radar signal 10 times a second.  An _AutoWeek_ reader and
bus driver reports that more than once he's been passed by a car moving at
speeds in excess of the speed limit and watched their radar detector light go
off.  Unfortunately the speeder usually pulls in front of the nearest large
target (you can guess what) and *slams on the brakes* to fool the non-existent
Smokey.  And, of course, busses go a lot better than they stop...

I find it funny that a system designed to prevent accidents could potentially
cause accidents by encouraging other drivers to make unsafe maneuvers.

Alan Dahl, Cellular Technical Services 2401 4th Ave., Suite 808, Seattle, WA
98121 PH: (206) 443-6400   alan@ctsx.celtech.com  ouunet!ctsx!alan


A310 Aerobatics

Karl Swartz <kls@ohare.chicago.com>
Tue, 1 Dec 92 13:58:49 PST
[This is from the latest issue of Airliners (Winter 1992); I'm amazed I
haven't seen anything about the incident elsewhere.  I'm posting the article
to sci.aeronautics.airliners as well and will pass along any RISKS-related
discussion that comes up there.  KS]

A310 Aerobatics

Following an autopilot-coupled go-around, the pilot attempted to counteract
the autopilot's programmed pitch-up by pushing forward on the control column.
(In most circumstances pushing on the control column disengages the autopilot
but automatic disconnect is inhibited in go-around mode.  The autopilot should
be disconnected or a mode other than go-around should be engaged through the
FCU - Flight Control Unit.)

As a result of the control inputs, the autopilot trimmed the stabilizer to -12
degrees (nose up) to maintain the go-around profile, but the elevator was
deflected 14 degrees (nose down).  After climbing about 600 feet (to around
2,100 feet) the autopilot captured its preselected missed approach altitude
and disconnected as the go-around mode was no longer engaged.  In the next 30
seconds, the grossly mistrimmed A310 pitched up to 88 degrees and airspeed
dropped to less than 30 kt.  (The stall warning activated then canceled itself
as the airspeed fell below usable computed values and the autothrottle system
dropped off.)  At 4,300 feet, the A310 stalled, pitching down to -42 degrees
while the pilot-applied control inputs showed full up elevator.  Airspeed
increased to 245 kt then the aircraft bottomed out at 1,500 feet, pulled +1.7
g, then climed rapidly.

The second pitch-up reached 70 degrees followed by a stall 50 seconds after
the first.  The nose dropped to -32 degrees and airspeed rose to 290 kt and
the aircraft bottomed out at 1,800 feet.  On the third pitch-up (to 74
degrees), the A310 climed to 7,000 ft then stalled again, about 60 seconds
after the second stall.  This time airspeed reached 300 kt in a -32 degree
nose down attitude before the aircraft leveled off at 3,600 feet.

The fourth pitch-up reached 9,000 feet but this time the crew's use of thrust
and elevator control (and very likely retrimming the stabilizer) prevented a
stall and the A310 leveled off at 130 kt.  Speed then increased accompanied by
another milder pitch-up to 11,500 feet where control was eventually regained.

All aircraft systems operated in accordance with design specifications.  The
reaction of ATC (the incident happened at Moscow) or the passengers is not
recorded.

Karl Swartz, 2144 Sand Hill Rd., Menlo Park CA 94025, USA 1-415/854-3409
kls@ditka.chicago.com   uunet!decwrl!ditka!kls
 Send sci.aeronautics.airliners submissions to airliners@chicago.com


New Distributed Systems Engineering Journal

Morris Sloman <mss@doc.ic.ac.uk>
Wed, 2 Dec 92 16:32:38 GMT
DISTRIBUTED SYSTEMS ENGINEERING JOURNAL --- Call for papers

A new journal on all aspects of the architecture, realisation and management
of distributed computing systems, for practising engineers and researchers in
the field.

First issue July 1993

Co-published by The British Computer Society, The Institution of
Electrical Engineers and Institute of Physics Publishing

Honorary Editors

Professor David Hutchison, Lancaster University, Department of Computing,
Bailrigg, Lancaster LA1 4YR, UK. Tel: + 44 524 593798 Fax: + 44 524 381 707
Email:dh@comp.lancs.ac.uk

Dr. Rafael Alonso, Matsushita Information Technology Laboratory
182 Nassau Street, Princeton, New Jersey, 08544 USA
Phone: + 1 609 497 4600 Fax:   + 1 609 497 4013  Email: alonso@mitl.com

Dr Morris Sloman, Imperial College of Science, Technology and Medicine,
Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK.   Tel:
+ 44 71 589 5111 ext 5040  Fax: + 44 71 581 8024  Email: mss@doc.ic.ac.uk

Editorial Board includes:

Dr Gordon Blair, Lancaster University, UK
Dr Brian Carpenter, CERN, Switzerland
Dr. Chris Cooper, Rutherford Appleton Laboratory, UK
Professor Flaviu Cristian, University of California at San Diego, USA
Mr Michel Gien, Chorus Systems, France
Professor Fred Halsall, University College Swansea, UK
Dr Peter Harrison, Imperial College,  UK
Dr Ian Leslie, University of Cambridge, UK
Professor Peter Linington, University of Kent, UK
Professor Andrew Lister, University of Queensland, Australia
Professor Krithi Ramamritham, University of Massachusetts, USA
Professor Santosh Shrivastava, University of Newcastle, UK
Dr James Stamos, IBM Research Division, USA
Dr Ralf  Steinmetz, IBM European Networking Centre, Germany
Dr Joseph Sventek, Hewlett-Packard Company, California, USA
Professor Mario Tokoro, Keio University/Sony CSL, Japan
Dr Ian Wilson, Olivetti Research Laboratory, UK

Scope

The area of interest of this journal centres on the integration of
processing, storage and communication subsystems within a distributed or
networked system.  The emphasis will be on distributed rather than parallel
processing and on practical engineering papers rather than theoretical
approaches. We particularly welcome papers from industry and those which
are based on implementation experience.

Distributed Processing

        Distributed processing architecture
        Distributed operating systems and environments
        Standards and open distributed processing (ODP)
        Configuration and management of distributed systems
        Computer architecture support for distributed processing
        Language support for distributed processing
        Algorithms and protocols to support distributed processing

Computer Networks

        Local, metropolitan and wide area networks
        Network architectures and protocols
        Network management
        Communications and network standards
        Open networking and open systems interconnection (OSI)
        Multiservice networks

Storage and Databases

        Data modelling
        Distributed data bases
        Distributed transaction processing
        Information retrieval and transformation
        Object stores
        Information and file servers
        Hypermedia systems

Information Systems & Applications

        Distributed multimedia systems
        Advanced home, business and industrial systems
        Computer support for cooperative work
        Distributed programming support environments
        User Interface design

These four main areas would be linked by consideration of system
dependability, fault tolerance, security, performance engineering,
timeliness or other architectural issues.

Submission Address

Submit five copies of papers for consideration to:

        The Executive Editor, Distributed Systems Engineering Journal
        The Institution of Electrical Engineers, Michael Faraday House
        Six Hills Way,       Stevenage,         Herts. SG1 2AY  UK
        Phone: + 44 438 313311         Fax: + 44 438 742 840
        Email: ieeproc@dm.rs.ch

If you need further details on the scope of the journal and other editorial
matters, contact the Honorary Editors.

Brief guide for authors

Contributions will be considered for publication in Distributed Systems
Engineering Journal if they have not been published previously and are not
under consideration for publication elsewhere. They must be in English and
should typically be 5000-6000 words in length.

The title page must include:
i)      title of article,
ii)     name(s) of author(s)
iii)    address(es) of establishment(s) where work was carried out;
iv)     short title of not more than 50 characters.
v)      abstract of not more than 200 words.

Details of format for final submission will be provided for accepted
papers. Authors who require more detail on presentation and style should
consult the booklet Notes for Authors, obtainable free of charge from IOP
Publishing at the address below or from the IEE.

Acceptance of papers for publication is subject to a peer review procedure
and may be conditional on revisions being made in the light of comments
from referees. However authors are solely responsible for the accuracy of
statements in a paper.

There are no page charges, and 50 offprints of each article published will
be supplied free of charge to the principal author.

Colour reproduction of illustrations is available but authors or their
institutions are asked to pay the additional costs incurred over and above
normal black on white reproduction. Authors requiring further advice are
invited to contact: the Production Manager, IOP Publishing Ltd, at the address
below.

Articles Submitted in Electronic Format

Articles can be submitted in Electronic format on IBM PC compatible or
Macintosh Discs.  The publishers can accept TEX source code. Authors who
intend to submit final version in electronic format should still provide
hard-copy versions for refereeing as normal.

For more details and specific guidelines on the preparation of articles in
electronic format, please contact:
        The Electronic Production Manager,
        IOP Publishing Ltd, Techno House,
        Redcliffe Way,         Bristol BS1 6NX, UK.
        Tel 0272 297481; Fax: 0272 294218.  Email: ioppl@gec-b.rl.ac.uk

Please report problems with the web pages to the maintainer

Top