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…
I thought the following article would be of interest to RISKS readers.
The risks of people disposing of equipment who are unfamiliar with the
technology used there in can lead to all sorts of interesting problems. GWD
From COMPUTER CURRENTS, Vol 4 #22, 7 April 1987, p68 from the NEWSBYTES
UK section by Steve Gold,
BARGAIN COMPUTER HOLDS STATE SECRETS
OXFORD, UK - Irangate had nothing on this one. The "London Times"
revealed last month that an Oxford student got more than he bargained
for when he bought a second-hand computer for 45 pounds ($68) at WS
Surplus Supplies in his home town.
Upon booting the used 64K CP/M computer, Mark Storer found an
array of expensive programs available, as well as more than 1,500
files still intact on the machine's 40Mbyte hard disk. When he peeked
at the files, Storer realized the computer's origin - The Royal
Signals and Radar Establishment in Malvern, Worcestershire.
Aside from being a Ministry of Defense establishment, the Malvern
site carries out some very hush-hush research into the kind of things
we can't print. Suffice it to say that the files included lists of
base personnel, their job descriptions and personal history, and a
full inventory, with costs, of the base since 1980!
"They effectively let me walk inside the base and look through
their files," said Storer, talking to the press of his find.
"NewsBytes UK" understands that the machine has now been returned to
the Defense Ministry and that a full investigation is under way.
From the Friday, 27 March 1987 edition of *The Providence Journal*:
Union official sues Journal for probe into background
PROVIDENCE - The interim administrator of the Providence Newspaper Guild is
suing the Providence Journal Co. and Equifax Inc. for $1,050,000, alleging
that they illegally used computerized personal information about her as part
of an investigation into her background.
In a suit filed Monday [ 23 March ] in U.S. District Court, Susan Zucker,
the interim administrator, said that the newspaper employed Equifax to
conduct an investigation aimed at providing information on her "character,
general reputation, personal characteristics, financial characteristics,
mode of living, strengths and weaknesses, estimated net worth, financial
difficulties, home surroundings and credit record."
Zucker asserts that Equifax submitted a report containing such information
to the Journal company.
She said both companies violated federal law governing how such information
may be used, because she was never an employee of the Journal Company nor a
candidate for employment, and because she never gave the newspaper nor
Equifax permission to review her background.
[ Neither of the companies would comment. ] ....
I found this notable not only because of the alleged misuse of computerized
records, but 1) because of how much information about details of the case
was not reported, and 2) that the charged newspaper printed the article at all.
Stephen W. Thompson, User Services Specialist, User Services
Brown U., Box P, Providence, RI 02906 USA (401) 863-3619
A recent report claims that the system installed at West Drayton (which controls Heathrow) fails several times a month. The hardware was installed in 1971 and the only other working version of it (in the UK) is in the Science Museum!! The report says that if the computer were a plane it would have been grounded years ago and that the CAA are not even handed about this situation. (They do admit that the near misses that occur are mostly due to operator error). A spokesman from the CAA has refuted these claims stating that there have been only two failures in 3 months due to software and one failure due to a faulty power supply. He also claimed that the hardware was not obsolete but that it was due for replacement in two years time. The report was produced from confidential interviews with air traffic controllers by the Institute of Medicine and Avionics (??????) Sorry if this is a bit vague - it's second-hand information. Lindsay
I noted two items recently of interest here. 1. Operational errors by U.S. air traffic controllers increased by 18 percent in the three month period that ended March 26, as compared with the same period a year earlier... Many of the errors appear to be caused by poor cmmunication, lack of coordination and ineffective use of equipment. [From an internal FAA message from Keith Potts, associate administrator for air traffic control, SF Chron, 9 April 1987] 2. Air near-misses were up 29% in 1985 (758) over 1984 and up 42% in 1986 (839) over 1984. [PBS, 9 April 1987] Another source cited 866 near air collisions in 1986, with 497 near-misses on the ground. It also noted that the shortage of controllers had resulted in their being paid overtime three times as much as previously... [SF Chronicle, 10 April 1987]
In RISKS 4.72 Phil Ngai <{ucbvax,decwrl,hplabs,allegra}!ampcad!phil} writes
about reactivity control in American nuclear submarine reactors. In
addition to those, all NRC-licensed reactors have the negative temperature
coefficient of reactivity he describes. Also, when pressure is lost the
boiling in the core greatly reduces reactivity. It also ensures heat
removal with the coolant pumps out of action, provided the vessel and
pipes are full of water. Kraftwerk Union even has a natural convection
reactor without any pumps. These are good examples of inherently safe
systems, provided water flood can be assured, as in a bathtub design.
Flooding a naval reactor with seawater would shut it down since the
chlorine in the water absorbs neutrons. I believe that river water would
not give a sure shutdown unless the pollution level was quite high. In
commercial reactors there are large reserves of water loaded with borate,
a strong neutron absorber, to be actively injected into the core. Active
injection is not inherently safe. A bathtub would be better.
James F. Carter (213) 206-1306
UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024-1600
UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@CS.UCLA.EDU
From RISKS 4.72: (_The Hunt for Red October_, and _Submarines_) ... The author of "..Red October" has never been underway on a US submarine. He has talked to a lot of people, and taken a civilian tour certainly. He makes a great yarn, and invents some plausable explanations, but (unless someone PUT IN those gross errors I noted) he guessed it all. The reactor coolant is regulated to within a few degrees, and in operation is held much more closely than that, with some variation, soon corrected, upon a change in bell (speed order). It may be that the author knew this, since it is obvious that thermal stress is undesirable, but needed a way to have a core meltdown for plot reasons. (there is also NO installed way to flood the RC, submarines BARELY float as it is) Since this is not in line with comp. risks, the subject should be dropped from this forum. I would like to offer my services as a source of correct information in the future. I won't give away secrets, but it will be the truth. If you, or anyone else has questions on the errors in that book, or US attack submarines in general, feel free to write to me. This is not the first time I have gagged on a statement on submarine operations or equipment as posted in this group. Jim Hunt hunt@ucbcory.Berkeley.EDU hunt@ucbcory.BITNET (Ex. ET2(SS) )
I don't see this as a risk that can be eliminated without a whole lot of
sensing and evaluation of the pilot's real-time condition.
The G-limits programmed in operate on the assumption that the pilot is
actively helping keep himself concious... there are physical acts a pilot
can take under that will help keep him concious while undergoing Gs. In
the Candian F-20 crash, the report mentioned that the pilot had flown the
sequence several times that day, and that he was probably somewhat
fatigued. It speculated the pilot may have not been as enthusiastic with
his anti-G straining, and the G-induced loss of conciousness resulted.
Obviously, the flight computer needs to sense the pilot's physical state,
and back off the Gs if the pilot shows signs of going under. Fighter
pilots are not going to like this, of course, since it takes an element of
control out of their hands. The problem of how to hook up the appropiate
sensors to the pilot, while allowing him full freedom of movement and
quick, *gentle* disconncection during ejection, is left as a problem for
the reader...
Ron Wanttaja (ssc-vax!wanttaja)
Peter Ladkin writes:
>The risk is that a pilot may plan on losing some brain function to
>g-forces, without risking that the plane will go out of control in the
>maneuver. This possibility ... leads pilots to enter maneuvers in which
>they do in fact lose consciousness, inadvertently.
I think the causality is blurred in this example. I think this is more a case
of risk-taking overriding risks (trying). High performance aircraft like the
F-16 are actually capable of even greater G turns. We have an aircraft name
the HiMAT which I think will take a 20G, but it is a remotely piloted vehicle.
When you use words like "due to" and "leads," these are implications against
the computer when in fact pilots are pushing their bodies' envelopes and not
the plane's envelope. [The computer "made me do it"?]
>Were the flight control computer not to assure maneuvering within the
>envelope in the event of an extreme g maneuver, no pilot would risk
>loss of control through impaired function, unless in combat.
See Top Gun. Try also "simulated combat." I don't vouch for the realism
of the movie only the personalities of this type of flyer (push the limits).
Remember, the computer is NOT programmed to take the controls
from the pilot in event of backout, and it's not clear to me that it
should [Pilot's associate for pilots out there?].
I decided to comment about this note because it was from Peter (a known
risk-taker) when some friends and I met him (we went to do the same rock
[climb] down in Pinnacles Natl. Mon. [separate parties]). I think
the situation is somewhat like putting a computer on own's back which
prevents one from climbing above some rating (while trying to push one's
skill ever higher).
--eugene miya
Cable TV risks attributed to software, and subsequent risks of bodily harm -- From the San Diego Evening Tribune (TV/Radio critic's column), April 9, 1987: Pay per view. It's as important to some people as their telephones, and when it doesn't work as well, they get very unhappy. Like Monday night when the Sugar Ray Leonard - Marvin Hagler middleweight title fight live from Las Vegas went down for the count in thousands of San Diego households. In what Cox Cable general manager Robert McRann calls "a software problem...a programming mixup," 4,510 customers missed part or all of the fight after they paid $30 to $40 for pay-per-view coverage. People got so upset that Cox had to call the cops when some 300 frustrated people began milling around the lobby at Cox's Euclid Avenue headquarters. Apparently all ended relatively well. No violence was reported, and Cox customers got refunds and/or vouchers for future cable pay-per-view events. Cox spokespeople asserted that this was their first serious problem in over two years of pay-per-view baseball games, movies, and other special events such as the recent Wrestlemania, for which over 10,000 people (!) signed up. --Walt Thode (thode@NPRDC)
[The following message was submitted to RISKS by 6 different people.
I initially thought it might already have been widely circulated, but
its repeated receipt has led me to include it here anyway. PGN]
By now, many of you have heard of (or seen) the broadcast message I sent to
the net two days ago. I have since received 743 messages and have replied to
every one (either with a form letter, or more personally when questions were
asked). The intention behind this effort was to show that I wasn't
interested in doing what I did maliciously or in hiding out afterwards and
avoiding the repercussions. One of the people who received my message was
Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he
wasn't exactly pleased. (I hear his Interleaf windows got scribbled on)
So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my
screen??"
I will attempt to explain.
I head a small group here at Berkeley called the "Distributed Unix Group".
What that essentially means is that I come up with Unix distribution software
for workstations on campus. Part of this job entails seeing where some of
the novice administrators we're creating will hang themselves, and hopefully
prevent them from doing so. Yesterday, I finally got around to looking
at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
was obvious that this was set up for rwall to use, so I read the documentation
on "netgroup" and "rwall". A section of the netgroup man[ual] page said:
...
Any of three fields can be empty, in which case it signifies
a wild card. Thus
universal (,,)
defines a group to which everyone belongs. Field names that ...
...
Now "everyone" here is pretty ambiguous. Reading a bit further down, one
sees discussion on yellow-pages domains and might be led to believe that
"everyone" was everyone in your domain. I know that rwall uses point-to-point
RPC connections, so I didn't feel that this was what they meant, just that
it seemed to be the implication.
Reading the rwall man page turned up nothing about "broadcasts". It doesn't
even specify the communications method used. One might infer that rwall
did indeed use actual broadcast packets.
Failing to find anything that might suggest that rwall would do anything
nasty beyond the bounds of the current domain (or at least up to the IMP),
I tried it. I knew that rwall takes awhile to do its stuff, so I left
it running and went back to my office. I assumed that anyone who got my
message would let me know.. Boy, was I right about that!
After the first few mail messages arrived from Purdue and Utexas, I begin
to understand what was really going on and killed the rwall. I mean, how
often do you expect to run something on your machine and have people
from Wisconsin start getting the results of it on their screens?
All of this has raised some interesting points and problems.
1. Rwall will walk through your entire hosts file and blare at anyone
and everyone if you use the (,,) wildcard group. Whether this is a bug
or a feature, I don't know.
2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
who you are as long as you're root (which is trivial to be, on a work-
station), I have to wonder what other RPC services are open holes. We've
managed to do some interesting, unauthorized, things with the YP service
here at Berkeley, I wonder what the implications of this are.
3. Having a group called "broadcast" in your netgroup file (which is how
it comes from sun) is just begging for some novice admin (or operator
with root) to use it in the mistaken belief that he/she is getting to
all the users. I am really surprised (as are many others) that this has
taken this long to happen.
4. Killing rwall is not going to solve the problem. Any fool can write
rwall, and just about any fool can get root priviledge on a Sun workstation.
It seems that the place to fix the problem is on the receiving ends. The
only other alternative would be to tighten up all the IMP gateways to
forward packets only from "trusted" hosts. I don't like that at all,
from a standpoint of reduced convenience and productivity. Also, since
many places are adding hosts at a phenominal rate (ourselves especially),
it would be hard to keep such a database up to date. Many perfectly well-
behaved people would suffer for the potential sins of a few.
I certainly don't intend to do this again, but I'm very curious as to
what will happen as a result. A lot of people got wall'd, and I would think
that they would be annoyed that their machine would let someone from the
opposite side of the continent do such a thing!
Jordan Hubbard, jkh@violet.berkeley.edu, (ucbvax!jkh)
Computer Facilities & Communications, U.C. Berkeley
Please report problems with the web pages to the maintainer