The RISKS Digest
Volume 9 Issue 31

Wednesday, 4th October 1989

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

Computer multiplies taxable earnings by 100
Rodney Hoffman
Hackwatch spokesman charged
Dave Horsfall
Re: Internet cracker on the loose
Randy Buckland
Re: Hospital problems due to software bug
Mike Kimura
Re: Date manipulation and end of millennia
Henry Spencer
Re: Clock-watching
George L Sicherman
9-digit precision
Gideon Yuvall
The Risks of Crossing the Tracks (Railroad Crossing Gate Technology)
Jean- David Beyer
Laurence Larry Sheldon
Richard L. Piazza via Chuck Weinstock
Fifth Annual Computer Security Applications Conference
Marshall D. Abrams
Info on RISKS (comp.risks)

Computer multiplies taxable earnings by 100

Rodney Hoffman <Hoffman.ElSegundo@Xerox.com>
4 Oct 89 07:17:53 PDT (Wednesday)
>From the 'Los Angeles Times' 2-Oct-89:

Hundreds of independent employees who worked for Wells Fargo Co. two years ago
were stunned to learn of a computer error that multiplied their earnings by 100
before passing on the information to the Internal Revenue Service.  The IRS,
eager to collect Uncle Sam's share, has written to the taxpayers, demanding an
explanation for the discrepancies between the Wells Fargo reports and the
recipients' 1987 tax returns.  "I was panicked.  They moved the decimal point
two places to the right," real estate appraiser Harold M. Samuelson told the
Salinas Californian.


Hackwatch spokesman charged

Dave Horsfall <dave@stcns3.stc.oz.au>
Wed, 4 Oct 89 09:22:35 est
This item, taken from "Computing Australia" 2nd October, should warm
the cockles of a few hearts...

``Hackwatch spokesman charged

  Self-styled computer security expert Paul Dummett, alias Stuart Gill,
  has been charged with making false reports to the Victoria Police
  following an investigation into claims he made in the daily media late
  in 1988 and early this year.  The articles often quoted Gill,
  introducing himself as a spokesman for either "Hackwatch" or the "DPG
  monitoring service".

  Gill claimed hackers in Australia had gained access codes from others
  in the US and lifted $US500,000 from the International Citibank, US.
  Other claims: credit card numbers had been posted on bulletin boards
  for BBS users' access; drugs, including steroids, were being sold
  using bulletin boards; evidence of this had benn given to the police
  by informers; and in response, the police had raided several hackers'
  homes.  The police, including the Criminal Investigation Bureau and the
  Fraud Squad's Computer Section, repeatedly denied the claims.

  Gill had disappeared, but returned again on September 22 and was
  charged in the Frankston Magistrates' Court under his real name, Paul
  Dummett.  According to court documents, police investigating Dummett's
  claims allegedly found Citibank's computer network had not been
  illegally accessed on its New York number as Dummett had claimed.
  When Dummett appeared in court his legal aid counsel Serge Sztrajt
  applied successfully to adjourn the case to October 20.  Dummett did
  not enter a plea.''

Dave Horsfall (VK2KFU),  Alcatel STC Australia,  dave@stcns3.stc.oz.AU
dave%stcns3.stc.oz.AU@uunet.UU.NET,  ...munnari!stcns3.stc.oz.AU!dave


Re: Internet cracker on the loose

Randy Buckland <rcb@ccpv1.ncsu.edu>
Tue, 3 Oct 89 10:00:46 EDT
We have also been hit by this person. We managed to trace some of his
activities. He broke into an account that saved it's history file and
we saw some of what he did to get root access. **** THERE IS A SECURITY
HOLE IN V3.0 ULTRIX **** This hole is fixed in 3.1. This problem has not
been mentioned in any DEC communications we have received. If you are
running 3.0 and this person can break into a normal account, he can get
root access with no trouble.

Randy Buckland   rcb@ncsuvx.ncsu.edu


Re: Hospital problems due to software bug (RISKS-9.26)

Mike Kimura <MNK@draco.hac.com>
Mon, 2 Oct 89 18:53:59 PDT
In RISKS-DIGEST 9.27, Will Martin wrote:
> I was hoping that someone out there has kept track of and will post a note
> listing those magic dates for various OS's and systems. It will be a useful
> reference for all of us.

The base time for VAX/VMS is November 17, 1858 (which is the base of the
Modified Julian Day system).  VAX/VMS uses 63-bit absolute time
representation (negative values are delta time representations) with a 100
nanosecond granularity therefore the last absolute time value that can be
represented is:

    July 31, 31086 at 02:48:05.47 AM.

However, all date/time routines within VAX/VMS allow for only 4 digits for
the year field so after 31-DEC-9999 the year field will look like
1-JAN-****.
                                                  Mike

Michael Kimura, Hughes Aircraft Company (RSG), P.O. Box 92426  MS: R2/9A37
  Los Angeles,  CA  90009       (213) 615-9775


Re: Date manipulation and end of millennia

<henry%utzoo@neat.cs.toronto.edu>
Tue, 3 Oct 89 11:54:18 EDT
>It has been suggested that if the year is divisible by 4000 then it
>should NOT be considered a leap-year.  Anyone writing code thats likley
>to be around 2000 years hence???

This is actually just a specific manifestation of the fact that calendar
reform requires altering timekeeping programs to match.  Leap millennia
are *not* officially part of the calendar, last I heard; anyone who writes
code on that basis has goofed.

I do recall some amusing ads for digital watches (back when they were new)
whose timekeeping was guaranteed accurate to the year 2099.  That is, the
designers didn't feel like allowing for leap centuries, and lucked out on the
year 2000 following the same rules as normal leap years.

                                        Henry Spencer at U of Toronto Zoology


Re: Clock-watching (RISKS-9.30)

George L Sicherman <gls@odyssey.att.com>
Tue, 3 Oct 89 22:17:22 EDT
In Risks Digest 9.30 Randall Davis decries the practice of transmitting
an image of a clock:

> Thousands of TVs?  An expensive television camera doing nothing but
> sitting there focused on a clock?  All those cables, monitors, all that
> power, bandwidth to burn on the network, etc.?

What a waste of resources indeed!  That expensive equipment was meant for
Geraldo Rivera, "Roseanne," and reruns of "Family Ties"--not for frivolous
ends.

I can't wait till we have high-definition television....

(N.B.  I do not speak for AT&T!)

Col. G. L. Sicherman


9-digit precision

Gideon Yuvall <gideony@microsoft.UUCP>
Wed Oct 4 08:51:49 1989
A recent report "Macintosh S/W markets: productivity S/W review & forecast,
1998-1993" (International Data Corp, 8/89) predicts that, in 1993, the U.S will
buy so many millions, nine hundred twenty-nine thusand, five hundred AND
FIFTEEN dollars' worth of Mac word-processing software. The leading digits have
been suppressed to protect the publisher's interests; but given that all nine
digits have been published, I wouldn't trust them that far anyway. This is a
reasonably expensive report (a few hundred $) which probably affects a good
many high-level management decisions.

I think this tomfoolery is relevant to comp.risks on two grounds: (1) it's a
textbook demo of common sense abdicating in the face of "the computer says so";
(2) I was told "that's Excel's default-mode for output" (and — I think --
other spreadsheets' too).

I was also told "that's what they learn in business school!". I hope not.

Gideon Yuval, gideony@microsof.UUCP, 206-882-8080 (fax:206-883-8101;TWX:160520)


The Risks of Crossing the Tracks (Railroad Crossing Gate Technology)

Chuck Weinstock <weinstoc@SEI.CMU.EDU>
Wed, 04 Oct 89 10:48:52 EDT
On the day that New Jersey Transit inaugurated service to Atlantic City, there
was a grade crossing accident that provoked a discussion of crossing gate
technology on the newsgroup rec.railroad.  It is interesting to note how an
"old" industry operating in difficult conditions (equipment outside, subject to
all sorts of environmental problems, not to mention vandalism) solves a safety
problem.
                                        Chuck Weinstock

>From: beyer@holin.ATT.COM (Jean-David Beyer)

I have some notes from General Railway Signal Company on railroad signalling.
There are separate sections on Wayside Signals, Crossing Gate Signalling,
Cab Signals, Frequency Shift Overlay Signalling, and so on.

The stuff is fool-proof, but not damn-fool proof. It cannot keep people
from going around crossing gates.

If the power source of signalling goes out, signals fail to stop.  If rails
break, signals fail to stop. If vandals short out the rails, signals go to
stop. If insulating joints fail to insulate, signals go to stop. If relays
springs break, signals go to stop. If relay coils open, signals go to stop. If
a lamp burns out, this is detected and the least restrictive aspect more
restrictive than desired is displayed.  Get the idea?

However, a suitably well-informed vandal could break the rail, having
previously put heavy electrical bonds around the gap, and wreck a train.

Or he could make his own code transmitters and couple them into the
rails (after disabling the real ones). But it is a lot of trouble to
do this without attracting the notice of the dispatcher.

Basically, when things go wrong, they fail safe. Even when someone around here
bumped an extruded aluminum crossing gate so that when it went up it hit the
12500 volt 1500 ampere catenary. It melted the gate and fried a couple of
relays in the control bungalow. The gates stayed down until that was fixed.  On
the other hand, if the gates stay down longer than an unreasonable driver
thinks is a reasonable time, he will go around the gate and get hit by a train.
Sometimes a train is coming the other way from one that is stopped in a
station, such as at Bridge and Monmouth streets in Red Bank. An eastbound train
was stopped in the station with the intersection apparently clear.  The driver
could not wait a few seconds (less than 60) for the train to pull out and
started around the gate. Only then did he see the westbound train and stop
clear of the other track. That is the kind of damn-fool proof the system is not.

Engineers must assume a signal improperly displayed is displaying the most
restrictive aspect that the signal is capable of (under most conditions).  Car
drivers should assume that if a gate is down, that they do not have time to get
around the gates. Sometimes they do, but it is a dumb thing to bet your life on.

> From: lsheldon@cup.portal.com (Laurence Larry Sheldon)

On the SP Penninsula Line (and others--it seems like) there is a white light
that shines down the right-of-way in each direction--if it is a bells and
lights only crossing, the light blinks in concert with one of the red lights
(in many cases it is a lens in the side of the red lights case).

If there is a gate, the white light does not flash unless the gate is down.

There seems to be a rule that the train must stop (or maybe it's run dead-slow)
if the white light is not blinking.

This is based on observation, not knowledge of the facts.

> From: lsheldon@cup.portal.com (Laurence Larry Sheldon)

On the SP again--if a train stops at a station (or in areas where switching
activity is high) the gates open up again if the train does not cross within
some time limit.  The engineer has to "whistle" the gate back down (there are
post-mounted microphones--actually loudspeakers-used-as- microphones) before
proceeding.  On some non-main line tracks there is a "STOP" sign at the
pavement (White on rectangylar red)--when the train gets to the stop sign, the
gates come down.

> From: beyer@cbnewsh.ATT.COM (jean-david.beyer)

G.R.S. have some motion detector circuits available. I do not know if they use
doppler detectors, or rate of change of signal amplitude, or what.  But they
are used where there is a lot of switching activity near a grade crossing. If a
train starts toward a crossing at over 2 mph, the gates come down. If the train
stops, the gates go back up. If the train resumes, the gates come down again.
If the train reverses (goes away from the intersection), the gates stay up.
Costly enough that they are not used much around here. But there is little
switching on the NJ Coast Line.

I have been told that some such units estimate the speed of the train, and wait
a while before putting the gates down if the train is coming slowly. This seems
theoretically possible, but I have seen no written information about that.

> From: beyer@holin.ATT.COM (Jean-David Beyer)

None of the Operating Rules I have read (but I have only about a 1974 Central
Railroad of New Jersey and a NORAC from early 1988) specifically discuss such
lights.  <<The blinking white light referred to previously...CBW<>

However, my G.R.S. notes say that if the white light does not flash (the one
you can see out the side of the red flashers for motorists), the signal
maintainer should be notified. (I.e., the signals are not working.)

There are rules dealing with flagging over grade crossings. I do not remember
them exactly, but they deal with situations where the flagman has defeated the
crossing protection (by putting a key in a lock switch) for local switching.
Then he must provide flag protection until the train physically blocks the
intersection (unless he can resume the crossing protection for some period of
time before the train movement is resumed).

> From: rich@linus.UUCP (Richard L. Piazza)

I have noticed that the amount of time between the lowering of the gates and
the actual passage of the train is sometimes VERY long.  I never would go thru
the gates, but I am sometimes tempted — especially when everybody else is
doing it.

I bet less people would try to go thru the gates if there was less of a time
lag.

Has anybody else noticed this?  Is there a standard for the amount of time that
the gate must be down before the train arrives?

> From: beyer@holin.ATT.COM (Jean-David Beyer)

I think you are right: if gates went down only a short time before the arrival
of the train (or, more exactly, before the train occupied the crossing), and
then went up as soon as the train departed, less people would go around.

I do not know what the standard times are, but I am sure they exist.  I do know
that around here, they flash the lights and ring the bell for 6 seconds before
the gates come down. Unless the lights and gates are coupled to the municipal
traffic signals. Then they get a little more time, so the traffic signals get a
chance to go red across the tracks.  For ordinary crossing circuits, the gates
come down when the train hits the approach track. Since, around here, no
insulated joints are required for the gates (Frequency Shift Overlay circuits),
the approach can be any length decided upon by the railroad. But it must be
long enough so that the fastest train will get the gates down in time. Since
rules prohibit speeds in excess of 79 miles per hour where there are grade
crossings, you can calculate the amount of approach track needed if you know
how much advance warning you need (someone who got on the tracks as the gate
closed behind him needs time to get off before getting hit by the train).

But if a train is going significantly slower, the gates can be down quite a
while. My "calibrated eyeball" says the approaches to the Red Bank New Jersey
crossings are about 1/2 mile long.

What seems to annoy people around here is when the train is stopped in the
station. The gate is down because the train is about to leave. But it may be
there a while if people take a long time to get off and on.  THis makes people
want to go around the gates. By Murphy's law, there will be an unseen train
coming the other way that will hit them. Luckily, I have never seen an accident
like that, but I saw a close one recently.

Also, if it has not rained for a long time, lots of potentially conductive crap
builds up on the ballast. When the rain first starts, this can bring down the
gates until it washes off.

When you figure that the resistance between the rails can go as low as 1/4 ohm
from rain and dirt, and that the shunting resistance of the trains can go up as
high as 0.06 ohm, it does not leave the signal system with a lot to work with.

Movement detectors could put the gates up if a train stops or slows down
appreciably. But they cost much more.  At Long Branch, the gates are up even
when the train is on the approach to the crossing, since the trains stay there
to wait for the shuttle from Bay Head. To make the signal go from Restricting
to Approach-Limited, the conductor operates a key in a lock that puts the gates
down. This is a nuisance, but it must have been considered to be cheaper than
motion detectors.

There may well be a grandfather clause that permits old stuff to be used.
The railroads do not seem to have a lot of money to pay for capital
improvements whenever something new comes out.


Fifth Annual Computer Security Applications Conference

Marshall D. Abrams <abrams%vlad@gateway.mitre.org>
Fri, 29 Sep 89 10:50:48 -0400
          Fifth Annual Computer Security Applications Conference
    (formerly the Aerospace Computer Security Applications Conference)
                            December 4-8, 1989
                   Westward Look Hotel, Tucson, Arizona

                               Sponsored by
             IEEE Technical Committee on Privacy and Security
                 American Society for Industrial Security
                  Aerospace Computer Security Associates

Conference Highlights

Keynote Speaker: Senator Dennis DeConcini (D - Arizona)
Luncheon Speakers: Mr.  Charles. T. Force, NASA and Mr. Dave Fitzsimmons,
  Cartoonist, Arizona Daily Sun
Distinguished Lecture in Computer Security: "INFOSEC: Where Are We Going?",
  Stephen T. Walker, Trusted Information Systems

Tutorial Program

Monday, 4 December 1989
  "Secure System Design - An Introduction", Morrie Gasser, DEC
  "Database Security", Teresa Lunt, SRI

Tuesday, 5 December 1989
  "Secure System Design - Advanced", Virgil Gligor, University of Maryland
  "A New Approach to Network Security", Jerome Lobel, Lobel Consulting
  "Computer Crime", Ms. Gail Thackeray, Arizona Assistant Attorney General

Technical Program, Wednesday - Friday, 6-8 December 1989

        Technical Paper Sessions
            +  Architecture  for Trusted Systems
            +  Network Security
            +  Cryptographic Applications
            +  Architecture and Mechanisms
            +  Security Policy and Models
            +  Risk Management
            +  Software Development for Security
            +  Data Base Security I  &  II
            +  Security for Command and Control
            +  Audit Applications
            +  Trusted Distribution
        Panel  Sessions
            +  Computer Crime
            +  Data  Base  Design  for MLS
            +  TCB Subset Issues
            +  Human Issues
            +  Gemini Users
            +  International INFOSEC Standards
            +  Integrity
            +  Shoot Out at the OSI Security Corral
            +  Civil Sector Security
            +  Security Standards for Open Systems
            +  Space Station Information Security
            +  Data Integrity and Security for Computer Aided
               Acquisition  and  Logistics Support  (CALS)

Special Events

Biosphere II: a prototype of the Earth for the future, Sonora Desert Museum:
  living animals and plants of the Sonoran Desert Region

Additional Information

For a copy of the advance program, which includes rates, schedule, registration
form, and special activities, contact:
  Diana Akers, Publicity Chair, (703) 883-5907 akers%smiley@gateway.mitre.org
  Victoria Ashby, Co-Chair, (703) 883-6368     ashby%smiley@gateway.mitre.org
     The MITRE Corporation, 7525 Colshire Dr., McLean, VA  22102

For exhibit informtion, contact Robert D. Kovach, Exhibits Chair,
  (202) 453-1182, rkovach%nasamail@ames.arc.nasa.gov

Please report problems with the web pages to the maintainer

x
Top