Subject: RISKS DIGEST 9.88
REPLY-TO:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Wednesday 2 May 1990 Volume 9 : Issue 88
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
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)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome.
CONTRIBUTIONS to
[email protected], with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to
[email protected].
TO FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
cd sys$user2:[risks]<CR>get risks-i.j . Vol summaries now in risks-i.00 (j=0)
----------------------------------------------------------------------
Date: 1 May 90 03:07:07 GMT
From:
[email protected] (Tom Kopp)
Subject: Booby-trapped contracted software
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]
------------------------------
Date: Tue, 1 May 90 16:22:49 EDT
From:
[email protected] (David Sherman)
Subject: Death rate inflated in St. Bruno area, health report finds
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.
------------------------------
Date: 1 May 90 19:52:42 CDT (Tue)
From:
[email protected] (Karl Lehenbauer)
Subject: Software Bug Causes Shuttle Countdown Hold at T-31 Seconds
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.
------------------------------
Date: Tue, 1 May 90 12:40:06 BST
From: Martyn Thomas <
[email protected]>
Subject: Criticism of "Glass Cockpits" (1)
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.
------------------------------
Date: Tue, 1 May 90 12:47:44 BST
From: Martyn Thomas <
[email protected]>
Subject: Criticism of "Glass Cockpits" (2)
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.
------------------------------
Date: Tue, 1 May 90 12:59:29 BST
From: Martyn Thomas <
[email protected]>
Subject: A320 Bangalore crash
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.
------------------------------
Date: Tue, 1 May 90 13:10:04 BST
From: Martyn Thomas <
[email protected]>
Subject: A320 criticisms reported
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.
------------------------------
Date: Tue, 01 May 90 14:04 PDT
From: ZENITH <
[email protected]>
Subject: Re: (Not necessarily) computer parks hundreds of cars illegally
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/
[email protected]> -
------------------------------
Date: Tue, 1 May 90 18:17:03 -0400
From:
[email protected]
Subject: (Apparently) widespread problem with census 800 number
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
------------------------------
Date: Tue, 1 May 1990 16:21:09 -0400
From: clewis%
[email protected] (Chris Lewis)
Subject: Re: You think YOU have problems with your telephone company?
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
------------------------------
Date: Mon, 30 Apr 90 12:20:58 EST
From:
[email protected]
Subject: Telephone switch problems
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?
------------------------------
Date: Tue, 01 May 90 19:22:29 PDT
From:
[email protected]
Subject: White paper available: "Improving the Security of Your UNIX System"
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
[email protected] [Many thanks, Davy. This is a goody. PGN]
------------------------------
Date: Wed, 2 May 90 22:26:08+0900
From: Yoshio Oyanagi <
[email protected]>
Subject: Virus found in a game software on the market
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)
------------------------------
Date: Tue, 1 May 90 10:24:59 PDT
From:
[email protected]
Subject: Re: Computers and names with special characters (Hoffman, RISKS-9.85)
>... 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...
------------------------------
End of RISKS-FORUM Digest 9.88
************************
