The RISKS Digest
Volume 9 Issue 88

Wednesday, 2nd May 1990

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Booby-trapped contracted software
Tom Kopp
Death rate inflated in St. Bruno area, health report finds
David Sherman
Software Bug Causes Shuttle Countdown Hold at T-31 Seconds
Karl Lehenbauer
Criticism of "Glass Cockpits" (1) and (2)
Martyn Thomas
A320 Bangalore crash
Martyn Thomas
A320 criticisms reported
Martyn Thomas
Re: computer parks hundreds of cars illegally
Andrew E. Birner
(Apparently) widespread problem with census 800 number
Timothy M. Wright
Re: You think YOU have problems with your telephone company?
Chris Lewis
Telephone switch problems
Webber
White paper available: "Improving the Security of Your UNIX System"
Davy Curry
Virus found in a game software on the market
Yoshio Oyanagi
Re: Computers and names with special characters
Bandy
Info on RISKS (comp.risks)

Booby-trapped contracted software

Tom Kopp <tkopp@carroll1.cc.edu>
1 May 90 03:07:07 GMT
A programmer from Waukesha Wisconsin (Name is in the article, I won't post it
here) is to be charged with "destroying computer data" and causing damage in
excess of $2,500.  If convicted, maximum penalties will be 5 years prison, and
$10,000 in fines.  The programmer wrote the code such that he could shut it off
at will in the future.  The client refused to pay, so he killed the software.
[Computerworld, 23 April 1990]


Death rate inflated in St. Bruno area, health report finds

David Sherman <dave@lsuc.on.ca>
Tue, 1 May 90 16:22:49 EDT
Toronto Star, May 1, 1990:

   Death rates in the St. Bruno school neighbourhood are not among the
highest in Toronto, as city records previously showed, and in some cases
are actually lower than the city-wide average.
   A study by city health officials says a "computer programming error"
incorrectly inflated death rates in the area by almost 100%, causing
widespread concern among residents....
   Corrected figures show that 12 to 13 people per 1,000 die in the
neighbourhood east of the school each year... Earlier statistics
claimed 22 of every 1,000 residents in that area die each year, a rate
almost three times as high as the city average....
   The new report said an age factor was incorrectly fed into the
computer calculations, lumping together all deaths of people over
age 65....
   St. Bruno was built on the site of a former steel plant.  The site
was also once occupied by the phototoxicology and radiation testing
laboratory operated by the environment ministry.
   St. Bruno has remained closed since March, when teachers and
students complained of unusual health problems, including six
teachers who had developed fibroid tumours and three who had
uterine cancer.
   Shortly after the school was closed, an incorrect report said
the two census districts immediately east of the school ... had the
second and third highest death rates in the city.


Software Bug Causes Shuttle Countdown Hold at T-31 Seconds

Karl Lehenbauer <karl@sugar.hackercorp.com>
1 May 90 19:52:42 CDT (Tue)
According to Aviation Week (April 30, 1990, pg. 24), a software problem caused
a three minute hold at T-31 during the launch countdown of the shuttle mission
that orbited the Hubble Space Telescope on April 24th.

At T-48 seconds, newly written software detected that the outboard external
tank liquid oxygen fill and drain valve was open when it should have been
closed.  The ground launch sequencer (GLS) stopped the countdown clock at
T-31 seconds.

George T. (Ted) Sasseen, director of shuttle engineering, said that the
software changes were made after an incident that occurred on April 2nd,
where a pipe burst and sprayed water over a 4,000 volt motor control
assembly, shorting it and causing the launch processing system (LPS)
control room to go down, prompting concern that the LPS could lose power
in the last few seconds of the countdown.  Sasseen said that unless oxygen
is drained within nine minutes after the flow is stopped, a phenomenon
called "geysering" could rupture plumbing and destroy the tank.

    "So the fix was to put a purge in that [liquid oxygen] line
    and to put a small gas pad in it.  We did that by hand after
    the inboard valve was closed and before the outboard valve
    was closed.  The GLS sent its 'close outboard' command at
    48 sec."

    He said that about 10 sec. after this happened, "everyone
    looked around and said, 'Oh boy.  We were dumb.'..."

    Sasseen said the processing team violated one of its own
    cardinal rules that says: Never make a software change
    unless you can run it many, many times in simulations and
    tests.  He said, "There are oddities about software changes
    that you don't always get the first time through.  And the
    basic rule we violated is that it wasn't tested enough."

    He said the purge/gas pad software may be removed because it
    is unlikely that there would be a total launch processing
    system launch between T-31 sec. and T-0.  "But I want to
    emphasize that the software safed the system as it was
    supposed to."

To their credit, the system engineers were able to determine what the problem
was and fix it within three minutes.  A more cautious approach might have been
to scrub the launch until a more careful analysis and review was performed.


Criticism of "Glass Cockpits" (1)

Martyn Thomas <mct@praxis.UUCP>
Tue, 1 May 90 12:40:06 BST
A leaked copy of the draft report by the Air Accident Investigation Branch into
the Jan 1989 737-400 crash at Kegworth, UK, criticises the ergonomics and
user-friendliness of the CRT and LED display systems and engine instruments,
according to Flight Int'l (May 2-8).  The crash occurred after the crew shut
down the wrong engine following vibration caused by a fan-blade failure.

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.


Criticism of "Glass Cockpits" (2)

Martyn Thomas <mct@praxis.UUCP>
Tue, 1 May 90 12:47:44 BST
Dr Roger Green, of the RAF Institute of Aviation Medicine, gave a lecture to
the Royal Aeronautical Society in late April 1990 in which he said that
operating in a digital "glass cockpit" increases the liklihood that pilots
will not maintain an independent mental picture of systems status and flight
profile - "always necessary for critical surveillance but also for dealing
with the unexpected" according to Flight Int'l (2-8 May 90).

This may have been a factor in the Korean Airlines KAL 007 navigation errors
which led to it being shot down by the USSR.

Green adds that cockpit ergonomics and instrument design are not subjected
to such exhaustive testing as are airframes: "The rigour with which these
things are evaluated leaves a lot to be desired".

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.


A320 Bangalore crash

Martyn Thomas <mct@praxis.UUCP>
Tue, 1 May 90 12:59:29 BST
The report in Flight Int'l (2-8 May 1990) on the Bangalore crash makes very
interesting reading. It is too detailed to summarise, and too long to post, but
the account of the number of "flight modes" which the A320 went through in the
two minutes before the crash, and the side-effects of each (which seem not to
have been understood properly by the pilots) makes operating an A320 appear
surprisingly complex and error-prone. It is certainly very different from
flying a fully manual airplane, and the secondary effects (such as selecting a
target altitude leading to the engines being retarded to idle, and needing
several seconds to develop full power again) need to be well understood by the
pilots.

I recommend the report in Flight, and I hope that someone who understands
the A320 systems is able to post an analysis of what went wrong to RISKS.

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.


A320 criticisms reported

Martyn Thomas <mct@praxis.UUCP>
Tue, 1 May 90 13:10:04 BST
Andrew McKechnie, in a letter in Flight Int'l (May 2-8) reports that the
February issue of Log (the journal of the British Airline Pilots'
Association) contains two observations on the A320 systems by an A320 pilot.

"The author, who has experience of flying the A320, claims that the display
of airspeed is less than compelling and also that he has 'experienced an
occasion when the autothrottle made no attempt to hold a correct speed'."

Comment by MCT: the latter point could be a misunderstanding of the active
flight mode and therefore of the speed which the fly-by-wire system deemed to
be correct. In other words, if the incident reported really occurred, it could
be evidence of a technical malfuction OR it could be evidence of the pilot's
difficulty in understanding what speed he/she had caused the computers to
select as the target speed. In either case it is relevent to RISKS.

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.


Re: (Not necessarily) computer parks hundreds of cars illegally

ZENITH <ZENITH@l66a.ladc.bull.com>
Tue, 01 May 90 14:04 PDT
I saw the TV reports (on the local NBC affiliate, Channel 5).  I'd like to add
a bit to what's been said so far about the (allegedly) undeserved parking
tickets:

   1) According to the news reports, the city blames the incident on human
      error--on the part of the officer issuing the ticket, the operator
      keying in the information, or both.  This time (see below), they didn't
      try to call it a computer error; that designation came from those
      reporting on the story.

   2) Illinois license plates indicate a registration type and plate number.
      Taxis have Taxi plates; the plate numbers end in TX, as well (e.g.
      12345 TX).  Livery vehicles have livery plates, with numbers ending
      in LV.  State and local governments have their own plate types, as
      do some utilities.  So, the same series of digits can appear on a
      large number of plates; other plate information must be used to
      distinguish among them.  If the other information does not make it
      into the computer, for whatever reason, the ticket will be charged
      to the wrong plate; if the other information is garbled, the same
      will happen.  I've had the misfortune to examine a number of parking
      tickets over the years; from what I've seen, the quality of the input
      documents (written in ink by an officer standing by the car, possibly
      in high winds and freezing rain) makes errors in transcription rather
      likely.

   3) This is not the first time this has happened.  Last time, back in
      about 1985, the city switched over to a ticket tracking system that
      didn't allow for a distinction among plate types.  When the data from
      the old system was transferred to the new, information was lost; all
      Taxi, RV, Livery, etc. tickets were charged to the passenger plates
      with the same number.  (The firm that got the contract was not based
      in Illinois; they had no idea what our license plates look like.  If
      this sounds to the reader as though the contract should not have gone
      to this particular company, you are not alone; the FBI and several
      federal courts have agreed with you, if I recall correctly.)

 The details above are from memory; corrections and amplifications are most
welcome.  The opinions are mine; they do not necessarily correspond to those
held by my employer or by any organization who might happen to forward my
email.

- Andrew E. Birner, Zenith Electronics Corp — <Zenith/A_Birner@ladc.bull.com> -


(Apparently) widespread problem with census 800 number

<twright@ATHENA.MIT.EDU>
Tue, 1 May 90 18:17:03 -0400
The recent postings about the woman in Florida and the (possibly malicious)
problems involved with her phones reminded me of problems of a decidedly
non-malicious problem I had involving the Census Bureau's toll free system.

Each census form sent by the Bureau of the Census was contained in an envelope
on which was printed a toll-free number to call in case of any questions
(800-999-1990).  I had a relatively simple question, and found that one of two
things happened on the 100 or so times I tried the number: either (1) a busy
signal (the usual result); or (2) a few rings, a few rings (pitched slightly
higher), then a click, and finally a connection, to another person with a
question!  The second case happened twice: both the other party and myself were
rather confused for half a minute or so.

I finally did get through to an actual Census employee, and I relayed my
problems with the phone system to her.  She replied that other callers had
relayed similar problems.  I wonder if the Bureau of the Census will fix its
phone system in the next ten years.

--timothy m wright--gradual student, political science, MIT


Re: You think YOU have problems with your telephone company?

Chris Lewis <clewis%eci386@uunet.UU.NET>
Tue, 1 May 1990 16:21:09 -0400
One particular scenario which is worth considering is that of intentional
sabotage by active insiders.  A few years back a new large telephone switch was
installed in a very high profile site to serve as a demonstration of
technological achievement and to garner additional sales.  The switch was
plagued for many months with severe problems, most along the line of partial or
complete service failure, and occasionally bizarre behaviour.  Made the papers
many times...  Rather embarassing to say the least.

Naturally, the service provider was concerned, and involved the switch
manufacturer who spent many months (and millions of dollars) analysing the
hardware and software, involving both the original R&D organization and outside
consultants to try to establish a cause.  All to no avail.

It wasn't until the manufacturer slipped in one of their own personnel into the
on-site maintenance crew (the provider was refusing to permit this) that the
problem was resolved: one of the service provider's onsite people was
intentionally shorting out signals (amongst other things reasonably difficult
to pinpoint after the fact).

Sorry to be so cagey.  I understand that most of this has been documented in
the press, but I'm not absolutely certain of the precise details, nor wish to
subject the companies involved with further embarrassment.  Especially since I
don't know whether or not the person was charged, what with, nor whether it was
successful, nor why he was doing it in the first place.

You may wish to treat this story as totally apocryphal, that's up to you,
but a scenario of active inside sabotage is certainly possible and should
be investigated by your contact's phone service.

Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis


Telephone switch problems

<webber@psych.toronto.edu>
Mon, 30 Apr 90 12:20:58 EST
My recollection of this is fuzzy, but the recent discussion of telephone
switch problems eventually reminded me of some major problems experienced
in Ottawa at an early Bell Northern installation.  Large numbers of
telephone misfunctions developed at this showcase operation, but I
believe they were eventually traced to the actions of a disgruntled
former employee.

I believe he was entering the equipment room and shorting conductors
together.  I'm sure that some Bell Northern folk who read RISKS are
better informed than I on this matter; perhaps some of them could comment?


White paper available: "Improving the Security of Your UNIX System"

<davy@itstd.sri.com>
Tue, 01 May 90 19:22:29 PDT
A new white paper from SRI International's Information and Telecommunication
Sciences and Technology Division is now available.

The paper, "Improving the Security of Your UNIX System," describes measures
that you as a system administrator can take to make your UNIX system(s) more
secure.  Oriented primarily at SunOS 4.x, most of the information covered
applies equally well to any Berkeley UNIX system with or without NFS and/or
Yellow Pages (NIS).  Some of the information can also be applied to System
V, although this is not a primary focus of the paper.

An abbreviated Table of Contents:

    1. INTRODUCTION
        The Internet Worm, the Wily Hacker, other break-ins
    2. IMPROVING SECURITY
       2.1 Account Security
        Passwords, expiration dates, guest accounts, group accounts,
        Yellow Pages
       2.2 Network Security
        Trusted hosts, secure terminals, NFS, FTP, TFTP, mail,
        finger, modems and terminal servers, firewalls
       2.3 File System Security
        Setuid shell scripts, sticky bit on directories, setgid
        bit on directories, umask values, encrypting files,
        devices
    3. MONITORING SECURITY
       3.1 Account Security
        lastlog, utmp, wtmp, acct
       3.2 Network Security
        syslog, showmount
       3.3 File System Security
        find, checklists, backups
       3.4 Know Your System
        ps, who, w, ls
    4. SOFTWARE FOR IMPROVING SECURITY
       4.1 Obtaining Fixes and New Versions
        Sun fixes on UUNET, Berkeley fixes, SIMTEL-20 and UUNET,
        vendors
       4.2 The npasswd Command
       4.3 The COPS Package
       4.4 Sun C2 Security Features
       4.5 Kerberos
    5. KEEPING ABREAST OF THE BUGS
       5.1 CERT
       5.2 DDN Management Bulletins
       5.3 Security-related mailing lists
    6. SUGGESTED READING
    7. CONCLUSIONS
    REFERENCES
    APPENDIX A - SECURITY CHECKLIST

In order to format the paper, the "troff" text formatter and the "-ms" macro
package (available with any Sun or Berkeley UNIX system) are required.  You
*do not* need a PostScript printer, unless you want to print the cover page
with the SRI logo on it.

The paper is available via anonymous FTP from the host SPAM.ITSTD.SRI.COM
(128.18.4.3) as the file "pub/security-doc.tar.Z".  Be sure to remember to
set "image" mode on the transfer.  Sorry, UUCP access is not available - if
you don't have Internet access, find a friend who does.

Enjoy.

Dave Curry

SRI International
Information and Telecommunications
Sciences and Technology Division
333 Ravenswood Avenue
Menlo Park, CA 94025
(415) 859-2508

davy@itstd.sri.com               [Many thanks, Davy.  This is a goody.  PGN]


Virus found in a game software on the market

Yoshio Oyanagi <oyanagi@is.tsukuba.ac.jp>
Wed, 2 May 90 22:26:08+0900
    VIRUS FOUND IN A JAPANESE GAME SOFTWARE ON THE MARKET

                                          Yoshio Oyanagi
                                          University of Tsukuba, Japan

     Newspapers reported on April 24 that a virus was found in a simulation
game software "FAR SIDE MOON" (9500 yen) for Sharp personal computer X68000.
It has been sold by Artdink Inc. since April 13 in Japan.  The virus was
detected by Computer Virus Institute (Takao Yamamoto, director) of Federation
of Japanese Computer Clubs.

     According to Yamamoto, this virus is programmed so that it keeps
inactive until July and after that data on floppy or in the computer will
automatically be erased whenever one switches on the computer.

     So far 3000 sets have been sold, among which half are contaminated.
It is conjectured that the computers in Artdink Inc. are invaded by the
virus while developping the game software.

     Today (May 2) Asahi Shinbun (one of the major daily newspaper in
Japan) disclosed that it succeeded in making contact with one of the virus
makers.  According to the report, the maker is a high school boy of age 17,
who lives in Kagawa prefecture.  Forty people collaborated in making the
virus and got several tens of thousand yen (several hundred dollars) for
each from the client, who ordered through PC network for hackers.  The
virus program was completed in three months and distributed secretly
since last September.

     Federation of Japanese Computer Clubs told that there have been
two viruses (viri?) for X68000, named "Namba I" and "Namba II".
"Namba I" becomes active on July 4 this year and it deletes data on
the computer or foppy disks.  If the computer is contaminated with
both "Namba I" and "Namba II", some X68000 do not accept any floppy
after 0:00 May 2.  The federation has developped a vaccine and
distributing it among PC shops and users. If, however, a computer
is contaminated with both viruses, it does not even accept the floppy
disk of the vaccine.  In this case, user should bring the computer
to the maker and ask to change the parts.

    (crossposted to comp.risks and comp.virus)


Re: Computers and names with special characters (Hoffman, RISKS-9.85)

<bandy@capmkt.com>
Tue, 1 May 90 10:24:59 PDT
>... Univac/Sperry/Unisys computers, I ought to change my name to @FIN

Or perhaps @@term ?  If I remember correctly the double master space
character can appear anywhere in a line...

Please report problems with the web pages to the maintainer

x
Top