Subject: RISKS DIGEST 14.50
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest  Wednesday 14 April 1993  Volume 14 : Issue 50

       FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

 Contents:
Head-on train collision in Berlin (Debora Weber-Wulff [2])
Discovery discovery of ozone data (PGN)
``Navy Calls Satellite a Total Loss'' (PGN)
Police data misused to find home address (Arthur R. McGee)
36,000 dollar bug! (John Pettitt)
Hardware GOOD, software BAD? (Caveh Jalali)
Re: ... San Francisco Muni Metro (Robert J Woodhead)
Re: Discovery shuttle problem (D King)
Re: Turn of the century date problems (Mark Brader)
Re: The FORTRAN-hating gateway (Bob Frankston)
IFIP Call for Papers (Harold Joseph Highland)

The RISKS Forum is a moderated digest discussing risks; comp.risks is its
Usenet counterpart.  Undigestifiers are available throughout the Internet,
but not from RISKS.  Contributions should be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious.  Diversity is
welcome.  CONTRIBUTIONS to [email protected], with appropriate, substantive
"Subject:" line.  Others may be ignored!  Contributions will not be ACKed.
The load is too great.  **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
especially .UUCP folks.  REQUESTS please to [email protected].

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 14, j always TWO digits).  Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential.  "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

For information regarding delivery of RISKS by FAX, phone 310-455-9300
(or send FAX to RISKS at 310-455-2364, or EMail to [email protected]).

ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: Sat, 10 Apr 1993 08:06:08 GMT
From: [email protected] (Debora Weber-Wulff)
Subject: Head-on train collision in Berlin

At 14:23 on Good Friday an Intercity train leaving Berlin collided head on
with a train approaching Berlin just outside the city limits near Wannsee.
This is a portion of track that is being electrified "under pressure", as the
German Bundesbahn wants to run its ICE trains on the line from May 23. During
the week only one track is used so that workers can work on the other track.
On weekends and holidays both tracks are available. The approaching train was
a "special train" that is added to the timetable for holidays to cope with the
traffic.

The trains were only going at 30 kmh because of the construction, and at least
one of the engineers saw the collision coming: he pulled the brake and jumped
the train, his co-engineer ran towards the back of the train and was severely
injured. Both engineers in the other train and a passenger were killed, over
20 were wounded, 7 remain in the hospital this morning.

There was much finger-pointing at first: both trains appeared to have proper
signals, as they were assumed to be on different tracks; the "Stellwerk" (is
that the switch controller?) was said to have been misoperated; each train
company (Wannsee is on the border between the DR and the DB train authority:
after 3 1/2 years of reunification they still haven't got the trains sorted
out) accused the other; workers were said to have inadvertently capped an
important cable. A blanket of silence has been imposed, the officials will
neither confirm nor deny anything at the moment.

Debora Weber-Wulff, Professorin fuer Softwaretechnik, Technische
Fachhochschule Berlin, FB Informatik, Luxemburgerstr. 10, 1000 Berlin 65

------------------------------

Date: Wed, 14 Apr 1993 07:38:37 GMT
From: [email protected] (Debora Weber-Wulff)
Subject: Follow-up on Berlin Train Crash

The preliminary results of the train crash in Berlin on Good Friday were
published in the "Tagespiegel" this morning.

It seems that the computerized signals worked perfectly: the
"Fahrdienstleiter", the person in charge of setting the switches and the
overseeing the signals set the switch wrong - to one-way traffic (workday)
instead of two-way traffic (holiday). The computer reacted by setting the
outbound signal correctly to "halt".  The overseer believed that this was a
defect in the system, and overrode the signal by setting the temporary extra
signal (which is just for when the track is under construction) to "proceed"
without telephoning anyone to investigate the supposed signal error. The
overseer overlooked [PGN would say: oversaw] the fact that a non-regularly
scheduled train was approaching the switch, he believed that the track was
free.

The risks question: How easy should it be for a person to override such a
system?  Or is this just a question of human error, to be accepted as
"Schicksal", fate?

Debora Weber-Wulff, Professorin fuer Softwaretechnik, Technische
Fachhochschule Berlin, FB Informatik, Luxemburgerstr. 10, 1000 Berlin 65

------------------------------

Date: Sat, 10 Apr 93 11:05:35 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Discovery discovery of ozone data

The current Discovery mission is monitoring ozone and several dozen other
atmospheric gases.  However, the on-board recorder does not have enough
storage for the full mission's data, and the data is supposed to be
transmitted back to earth.  Unfortunately, there is a high-rate data channel
problem on the shuttle antenna that is blocking transmission; NASA has been
unable to overcome that problem thus far.  [Source: San Francisco Chronicle,
10 Apr 1993, A5]

------------------------------

Date: Sat, 10 Apr 93 11:10:40 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: ``Navy Calls Satellite a Total Loss''

A Navy communications satellite launched via an Atlas rocket on 25 Mar 1993
was placed in an unusable orbit that was at one end thousands of miles too
low.  The Navy declared the mission a total failure on 9 Apr 1993.  [Source:
San Francisco Chronicle, 10 Apr 1993, A5]

------------------------------

Date: Sun, 11 Apr 93 06:01:29 -0700
From: [email protected] (Arthur R. McGee)
Subject: Police data misused to find home address

  [Abstracted by PGN from a UPI item forwarded by ARM from
  [email protected], datelined Anaheim, California]

An unidentified employee of the Anaheim Police Department apparently misused
his access to the DMV computer system to obtain the home address of a man who
had been targeted by anti-abortionists.  This led to Chris Criner's house in
Tustin CA being picketed in February 1993.

 ``It taught me I can't trust anyone,'' Criner said. ``When you find
 out the perpetrators of harassment were helped by the Anaheim Police
 Department, you wonder where does it stop.''

Under state law, unauthorized disclosure of DMV records is a misdemeanor with
penalties up to one year in jail plus a fine of $5,000.

------------------------------

Date: Tue, 13 Apr 93 20:53:19 PDT
From: John Pettitt <[email protected]>
Subject: 36,000 dollar bug!

It's that time of year, and I have just got my tax return back from the
accountant.  During 1992 I had to pay estimated tax on a capital gain from
selling stock.  The program my accountant used to calculate the amount had TWO
major bugs.

Firstly, it did not deduct the amount of state tax I was estimating I should
pay before estimating the federal.  Secondly, it ignored a foreign tax credit
when calculating alternative minimum tax.  The net result of this was a $36.8K
overpayment!  This was a well known PC-based commercial package used by many
accountants across the country.

Luckily for me, they changed the program before running the 1992 return and
found the mistake -- so I am out some $700 in interest for the period.

However it brings home that the tax code is now so complex that in many cases
advisors treat the output of their programs as beyond question.  Had the error
been the other way and not been found, the consequences in penalties, etc.,
could have been very worrying.

 [ For the non-US reader, the US tax code is a gothic monstrosity that nobody
   would believe if they had not seen it.  Being English, I thought the
   Inland Revenue was bad, but the US system is mind boggling in it's
   complexity and stupidity. ]

 [ For the tax-minded, I had a very complex foreign source and foreign
   capital gain transaction with UK tax credits, the total returns (Fed and
   California) are over half an inch thick. ]

John Pettitt

   [See a previous item by Edgar Knapp in RISKS-13.42, discussing a nasty
   bug in MacInTax.  John's could have been the SAME PROBLEM!  PGN]

------------------------------

Date: Sat, 10 Apr 93 11:25:51 -0700
From: Caveh Jalali <[email protected]>
Subject: hardware GOOD, software BAD?

There has been a considerable amount of traffic on the net concerning
Seagate's new 3.5Gb drives that came out a few months ago.  As it turns out,
SunOS (presumably the Berkeley file system) can't handle partitions over 2 Gb
(2^31 - 1), so one is forced to install the drive in two partitions.  Didn't
MS-DOS have a similar problem only yesterday...

What went wrong?  I can't imagine it is more difficult to design, build, and
market a 3.5Gb drive than it is to write/fix a file-system implementation to
support current hardware.

I just hope this happens before we hit the secondary limit of 8 partitions
per drive, or the tertiary limit of 8 LUNs (logical units) per SCSI device!

As a "software dude" i'm somewhat embarrassed to once again have been
outdone by the "hardware dudes"!

------------------------------

Date: Sat, 10 Apr 1993 13:56:38 GMT
From: [email protected] (Robert J Woodhead)
Subject: Re: ... San Francisco Muni Metro (Brennan, RISKS-14.49)

>>  ``... was the result  of the operator deliberately disabling the
>> safety system so that he could speed up his train, sources close to the
>> investigation said''.

>This is extremely bad, not only that the operator did it, but that he
>-could- do it.

Yes and No.  A safety system that cannot be disabled is, in itself, a risk, if
the system were to malfunction.

Far better is a safety system that, when disabled, leaves unmistakable
evidence that it has been meddled with, thus allowing responsibility to be
assigned, and providing a powerful incentive NOT to disable it without
justification.

A classic example would be to put the disabling mechanism behind a pane of
glass, with a hammer nearby, and a policy that "if the glass gets broken,
you'd better be able to explain why."

Robert J. Woodhead, Biar Games / AnimEigo, Incs.    [email protected] |
AnimEigo US Office Email (for general questions): [email protected] |

------------------------------

Date: Fri, 09 Apr 93 13:55:04 BST
From: [email protected]
Subject: Re: Discovery shuttle problem (Sorenson, RISKS-14.49)

>> ... The "fix" is to bypass the sensor, fooling the computer into
>> thinking the valve is properly closed.

In all fairness, they had alternate sources of information.

As was mentioned in sci.space and in RISKS a couple of days ago, they had
telemetry to monitor the temperature of the vent pipe that was downstream of
the valve and would have remained cold had the valve not in fact closed.

I don't know whether the software was told to worry about the vent pipe
temperature before the rewrite that got them off the ground, but i sincerely
hope that when they decided not to check for a valve closure indication they
also decided to check for this vent pipe temperature.  By now they should know
how this pipe temperature normally behaves.

And if the temperature doesn't rise fast enough, either the valve didn't close
or it's too cold for the %$#%&$#&^$*^ O-rings, anyway ;-) .
-dk

------------------------------

Date:   Fri, 9 Apr 1993 18:50:00 -0400
From: [email protected] (Mark Brader)
Subject: Re: Turn of the century date problems (Peterson, RISKS-14.45)

> In a humorous vein, I've regularly proposed a `programmer's cruise' that
> would depart on December 30, 1999.  The cruise would be 30 days long
> and would come with the following guarantees ...

There is a bug here.  Considering the number of people who seem to think that
2000 will NOT be a leap year, the cruise should extend at least into March!

Mark Brader, SoftQuad Inc., Toronto utzoo!sq!msb, [email protected]

  [Well, maybe it is more of an `opportunity' than a "bug".  PGN]

------------------------------

Date: Sat 10 Apr 1993 15:42 -0400
From: [email protected]
Subject: Re: The FORTRAN-hating gateway (Karn, RISKS-14.45)

The problem with "nnnn" in a gateway reminds me of the use of such sequences
as Telex end of message and as delimiters. I remember MMMM and LLLL so I
wouldn't be surprised at NNNN having a special significance. Perhaps they only
worked at the beginning of a line to reduce the likelihood of seeing them
during normal transmissions.

------------------------------

Date:  Mon, 12 Apr 93 14:24 EDT
From: "Dr. Harold Joseph Highland, FICS" <[email protected]>
Subject:  IFIP Call for Papers

                       CALL FOR PAPERS
       TENTH INTERNATIONAL INFORMATION SECURITY CONFERENCE
                    IFIP SEC '94  -  ARUBA

ORGANIZED BY IFIP TECHNICAL COMMITTEE 11 * Security and Protection in
Information Processing Systems * IN COOPERATION WITH THE SPECIAL INTEREST
GROUP ON INFORMATION SECURITY OF THE DUTCH COMPUTER SOCIETY AND CO-HOSTED BY
THE ARUBA COMPUTER SOCIETY.

                       MAY 23 - MAY 27, 1994
               PALM BEACH, ARUBA, DUTCH CARIBBEAN

The purpose of the Tenth International Information Security Conference IFIP
SEC '94 -- "Dynamic Views on Information Security in Progress" -- is to
provide an international forum and platform sharing experiences and
interchanging ideas, research results, development activities and applications
amongst academics, practitioners, manufacturers and other professionals,
directly or indirectly involved with information security and protection.  It
will be held at Palm Beach, Aruba, Dutch Caribbean on May 23rd-27th, 1994.

Those interested in presenting papers are invited to do so by September 30,
1993.  The papers may be practical, conceptual, theoretical, tutorial or
descriptive in nature, addressing any issue, aspect or topic of information
security.  Submitted papers will be refereed, and those presented at the
conference will be included in the conference proceedings.  Submissions must
not have been previously published and must be the original work of the
author(s).

The International Program Chair is particularly interested in papers on:

 Information security aspects in developing nations
 Security of health care systems
 Aspects of transborder data flow
 Fraudulent aspects and networks
 Security in banking and financial industry
 Evaluation criteria in information security
 Cryptology
 Risk management and analysis
 Contingency planning and recovery

Instructions to Authors

Five (5) copies of the complete paper, which should not exceed 25
double-spaced, typewritten pages, including diagrams, of approximately 5,000
words, must be received by NO LATER THAN September 30, 1993.

Diskettes and electronically transmitted papers will not be accepted.  Papers
must be sent to the International Program Chairman [address noted below].

Each paper must have a title page which includes the title of the paper, full
name(s) of all author(s) and their title(s), complete address(es) including
affiliation(s), employer(s), telephone number(s), telefax number(s) and e-mail
address(es).

To facilitate the blind refereeing process the author(s)' particulars should
only appear on the separate title page.  Furthermore, the first actual page of
the manuscript should include the title and a 100 word abstract of the paper,
explaining its contents.

Note: The language of the conference is English.  All submissions and
presentations must be written and delivered in the English language.  However,
at the conference Spanish translation will be available for the audience.

Notification of acceptance of submitted papers will be mailed on or before
December 31, 1993.  At that time author(s) will be instructed to prepare final
camera-ready manuscripts and the final deadline for submission of the
camera-ready manuscript is February 28, 1994.

Papers should be submitted to the International program Chair at the
Secretariat [address noted later].  All authors of submitted papers will enjoy
special benefits at the Conference.


The Referee Process

All papers and panel proposals received by the submission deadline will be
considered for presentation at the conference.  To ensure acceptance of high
quality papers, each paper submitted will be double and blind refereed.  All
papers presented at IFIP SEC '94 will be included in the conference
proceedings, copies of which will be provided to the attendees.  All papers
will also be included in the formal proceedings of IFIP TC11 to be published
by Elsevier Science Publishers (North Holland).


About the Conference

IFIP SEC '94 will consist of a five day/five stream program with advance
seminars, tutorials, open forums, special interest workshops and technical
sessions.  The conference will offer world-renowned and most distinguished
speakers as its keynoters, and the highest quality of refereed papers.  There
will be far over 100 different presentations.  This special conference will be
held at the convention space situated at Palm Beach on the Dutch Protectorate
island of Aruba in the Caribbean.

During the worlds' most comprehensive information security conference, the
second Kristian Beckmann Award, honoring the first chairman of IFIP TC 11,
will be presented.

IFIP SEC '94 is intended for computer security researchers, security managers,
advisors, consultants, accountants, lawyers, edp auditors, IT and system
managers from government, industry and the academia, as well as individuals
interested and/or involved in information security and protection.

The Tenth International Information Security Conference is organized by
Technical Committee 11 of the International Federation for Information
Processing, in cooperation with the Special Interest Group on Information
Security of the Dutch Computer Society, and will be hosted by the Aruba
Computer Society.


Conference Information

Aside from the submission of papers, which should be to the International
Program Chair, information about all other matters, including participation
registration, travel, hotel and program information, is available from the
General Organizing Chair at the Secretariat.

 SECRETARIAT IFIP SEC '94 ARUBA
 Postoffice Box 1555
 6201 BN   MAASTRICHT   THE NETHERLANDS
or
 SECRETARIAT IFIP SEC '94 ARUBA
 Wayaca 31a
 Suite 101/104
 ARUBA  -  DUTCH WEST INDIES

 Telephone:  +31 (0)43 618989
 Telefax:   +31 (0)43 619449
 Internet E-mail: [email protected]


Local Limited Contact

If you want you may communicate with  [email protected]
and I'll help if I can.  HJH

------------------------------

End of RISKS-FORUM Digest 14.50
************************