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…
"Voice mail user[s?] held up by hackers", by Paul Desmond, Staff Writer LOS ANGELES — A wholesale grocer here recently fell victim to a small band of hackers that comandeered the firm's voice-messaging systems and used it to run prostritution rings and pass information about drugs. The message system problems that have plagued Certified Grocers of California Ltd. (CerGro) highlight a threat to which many unsuspecting users may be vulnerable. Last October, some of CerGro's roughly 300 voice mail users began complaining that they were unable to access their voice mailboxes because their passwords had been invalidated. Upon investigation, Michael Marks, CerGro's communications supervisor, discovered that hackers had overcome the security features of the system and had reprogrammed up to 200 voice mailboxes for their own use. The hackers were accesssing the system using a toll-free 800 number CerGro maintained to let travelling employees call in for messages. [The article goes on to indicate the mailboxes were being used for data on stolen credit card numbers, cocaine prices, and male and female prostitution rings. CerGro removed the 800 number, and activity diminished. However, someone called to say that unless 10 voice mailboxes were established for their use, the intruders would cause damage. The mailboxes were established, but all subsequent messages were recorded...] [Source: Network World, 12 September 1988, courtesy of John Sheneman, 8319 Kostner Ave., Skokie IL 60076]
A note was posted regarding a New York Times report of a data entry error in a Delaware election. The fact that 2828 was keyed in instead of 28 is correct; Sam Beard was the recipient of these extra votes and not S.B. Woo. S.B. Woo, the current Lieutenant-Governor, now leads Sam Beard by approximately 80 votes in the democratic primary for Senator. S.B. should be declared the official winner sometime this morning. Andrew Frake, Academic Computing Support, University of Delaware
A couple of weeks ago, I voted in the annual election for the IEEE
executive. This election has an interesting new procedure: approval voting.
In this method, you can vote for as many candidates as you wish. The winning
candidate is the one who receives the most votes. This offers a number of
fascinating options. For example, you can can vote for the two best
candidates, or you can vote against someone by voting for everyone else. I
like this more than the Hobson's choice of a simple yes to one candidate.
What I would like to ask is: what can go wrong? For example, someone
could alter ballots by marking additional places which would be difficult to
detect because the number of votes cast does not have to equal the number of
voters. What else could go wrong? What robust safeguards could be put in
place?
Don
[Some of the other problems are noted in the Saltman, Hoffman, Nilsson works
recently cited, and in the talk by Eva Waskell summarized by Ron Newman —
see RISKS-2.42 (14 Apr 86), also in ACM Software Engineering Notes vol 11 no
3 (July 1986, pp. 14-16). PGN]
Re: Soviet Space Probe (dcf@ALLSPICE.LCS.MIT.EDU) (RISKS-7.52) Apparently, US craft have a "panic" mode that takes over if there is some problem ... are the panic commands in ROM so that they can never be overwritten?" I can't answer the question, but note that, for software operating in the occasionally high-radiation environment of space, "being in ROM" doesn't mean "can't be overwritten." -=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
A month or two ago, I wrote (RISKS-7.22) describing the Colwich Junction
train collision, on which a summary of the official report had appeared in
Modern Railways magazine. To summarize briefly, the accident was caused by
driver error; a contributing cause was overcomplication of the signal
system; and another contributing cause was poor braking. (One person--the
other driver--was killed; 32 of about 900 passengers were admitted to
hospital. Fair, for a 90-100 mph head-on collision.)
Modern Railways and/or I implied that the reason for the poor braking was
that the wheel slide prevention (WSP) system, i.e. anti-lock braking, had
acted. Several Risks readers said that this must be wrong, because antilock
braking should improve the braking, by keeping the wheel-rail friction
static rather than dynamic. [That's not actually obviously true, because
the wheel-rail coefficient of friction must be closer to the coefficient of
friction within the brakes in a train than are the corres- ponding values in
a car. And static friction at one place implies dynamic at the other. But
it seems probable that WSP should improve braking.]
I have now obtained further information, including the official report (thanks,
Clive Feather!). But the principal points (no pun intended) remain obscure.
First, I should point out that the WSP systems on British trains are not
actually designed to minimize the stopping distance. They are installed to
stop wheelslip for two *other* reasons:
- If a wheel slips during acceleration, it can spin so fast that the
frictional heat will damage both wheel and rail surfaces.
- If a wheel locks during braking, it will develop a flat spot,
requiring its surface to be reground.
The general principle is to compare speeds of different axles, and assume
slipping if they differ by more than some threshold. This obviously makes
the assumption that slipping wheels will slip unequally, which may not
actually always be true in the case of braking.
According to the official report on a different accident, the typical
coefficient of static (non-slipping) friction between rail and wheel on a
dry day is 0.3, and on a wet day 0.2; 0.1 suffices for normal braking, and
0.05 to prevent overrunning of signals (assuming no driver error). The last
two figures may vary from one line to another, and thus not be exactly right
for the Colwich Jct. area. Values worse than 0.05 occur only in conditions
such as heavy falls of leaves, or icing.
The unexplained part is this. All witnesses agreed on the speed of the
train. The driver and the other man in the cab agreed on where the brakes
had been put to emergency. A witness heard a repetitive air sound coming
from several cars, indicating that the WSP was operating and therefore that
the brakes were indeed on hard. But all witnesses also agreed that the
train decelerated more gently than in emergency braking. The investigating
officer made a considerable number of tests, and reproduced the actual
stopping distance only by driving the train about 10 mph faster than
everyone said — and running the test on wet track, when on the day of the
accident it was dry!
The WSP operates independently on every car, so multiple failures tending to
apply "too much protection" are not plausible. Actually, some of the
surviving WSP units did have faults in that direction, but not enough of
them to explain what happened.
The report's conclusions and recommendations read in part:
# Suffice it to say that I am satisfied that [the driver], once he
# realized that he was about to run past Signal CH23 at Danger,
# made a full emergency application of the brakes and there is no
# substantial evidence to show whether or not the brakes operated
# within the normal limits of efficiency. ...
# It is impossible to determine to what extent the operation of the
# wheel slide prevention equipment or any other factor reduced the
# efficiency of the braking, but there is no doubt that it was
# reduced to a certain extent.
Notice that this leaves ambiguous whether it was reduced by the WSP or
by something else. This is the report of an investigator who is stumped!
# A full emergency application of the brakes is likely to introduce
# wheel slide, even on dry rails, particularly if adhesion is reduced
# by any contaminant,
(One might guess that *that's* the answer, but there was no evidence.)
# and thus activate the wheel slide prevention
# equipment where fitted. Full emergency brake applications ... are
# made ... almost inevitably only when there is a true emergency.
# A very small distance may make all the difference ... and thus with
# the full emergency application of the brakes I believe that all
# brakes should be fully applied, even if wheel slide does occur
# and wheel flats are made on the wheels. I recommend, therefore,
# that consideration should be given to the fitting of equipment
# to automatically eliminate the operation of wheel slide prevention
# equipment in the event of an emergency brake application being made.
In short, the investigating officer, Major P. M. Olver, does not appear to
have considered the matter of static and dynamic friction; or perhaps Olver
is concerned more with the possibility of the WSP acting "by mistake" due to
a problem with it, but does not state this explicitly. One wishes that in
addition to trying to reproduce the accident, the test runs had included
some with the WSP disabled. The effect of that on the stopping distance
would have been highly germane to the recommendation of overridable WSP.
By the way, there have been several letters about the accident in Modern
Railways, but all commenting on the (pun coming) signal aspect. Perhaps
I'll write a letter about this point myself.
Mark Brader
Taken without permission from _The_Call_Board_, publication of the Mohawk & Hudson chapter of the National Railway Historical Society, which in turn took it from _Callboy_ of the Massachusetts Bay chapter, which in turn took it from _The_470_ of the Portland chapter: "About 125 children and 30 adults suffered from smoke inhalation after someone pulled the emergency brake cord on Amtrak's "Crescent" while it was in a tunnel near Washington Union Station on May 12, sending exhaust fumes spewing into the cars. The "Crescent" departed Washington southbound with two engines, 16 cars, and about 400 passengers and 18 crew aboard. Five minutes later, as the train was in the tunnel, an unknown person for unknown reasons pulled the emergency brake. The train stopped in the tunnel with its emergency brakes applied, and the second engine stalled or died. The train crew, thinking that an air hose that controls the brake system had parted, walked the train looking for such a problem. Finding none, the crew searched the cars and found that the emergency brake handle in the first car had been pulled. Unable to release the brakes, the crew shut down the lead engine. Trains that leave Washington Union Station going south immediately enter a 3,900-foot tunnel that roughly goes under the grassy Mall stretching form the Capitol to the Lincoln Memorial. Another Amtrak engine pulled the train back to the station, and buses retrieved the passengers from the hospitals to take them to hotels for the night." Would it not be fairly simple to install sensing devices in locomotive cabs, indicating when an emergency brake handle had been pulled? If the crew knew at once the cause of the automatic brake application, they would not have wasted time looking for broken air hoses. And why, upon finding the real cause, was the crew unable to then release the brakes? Emergency brake systems have been around for many, many decades. One would think that they would have been "perfected" by now. Comments from railroading experts? Michael Trout UUCP:brspyr1!miket BRS Information Technologies, 1200 Rt. 7, Latham, N.Y. 12110 (518) 783-1161
I have also had the experience of getting occupied hotel rooms mixed up by a clerk or computer, but which revealed a true software problem in the hotel's billing system. My wife and I had just arrived in LA from a 19 hour flight from Fiji, and missed my connection, so was jet lagged. The clerk gave us the key for room 456, but apparently entered 546 into the machine (as I found out the next morning.) 456 was unoccupied, so I didn't have any problem at the start. Unfortunately, about 3 a.m., someone else was assigned to 456 and woke us up. The dead bolt kept them out, but it sure messed up what little sleep we were getting. When we first arrived, we made several long distance calls that we expected to be billed to the room. Well, when we tried to pay the next morning, there was no bill. Since the computer listed 456 as empty (the 3 a.m. person was assigned another room, we were told), then there was no provision for recording phone calls. I would have preferred the sleep, but at least we got free phone calls for the trouble. However, the hotel lost revenue because the billing software didn't account for phone calls from empty rooms. I suppose if the staff knew that, they could take advantage. Bruce Wampler
Please report problems with the web pages to the maintainer