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…
(Well, after the reports of the President's plane affecting people's garage
doors, I guess it is appropriate that we are able to return the "favor"...)
Radio waves reportedly can down copter
By Mark Thompson, Knight-Ridder Service
(From the Boston Globe, 8 November 1987)
WASHINGTON - The Army's most advanced helicopter to carry troops into battle
can be knocked out of the sky by routine radio waves from microwave
towers, radio antennas, and radars, according to Pentagon officials and
documents.
Investigators believe such radio waves made five of the Army's UH-60 Black
Hawks nosedive into the ground since 1982, killing 22 servicemen. The
problem could be even more devastating in wartime, they said, because
the Soviets are perfecting a radio-wave weapon to exploit the vulnerability.
"We've got a very sophisticated electronic aircraft, and if the
radiation we're putting up in peacetime — microwaves, antennas, TVs --
is causing the aircraft to flutter and wobble, then — and I don't like
to talk about this because it is kind of a breach of security — we're
going to have problems in wartime," said Jerry A. McVey, a former Army
major who led the investigation into a still-unexplained Black Hawk
crash last year.
Radio waves in the air can enter the helicopter's wiring and
electrical components and generate false commands that can range from
simply flashing the warning lights to sending the craft into a fatal dive.
The Army recently warned its Black Hawk pilots that flight near radio
towers can cause unexpected dives that could endanger the $6 million aircraft.
"Pilots should be made aware that flights near microwave antennas or
shipboard radar may cause uncommanded attitude changes," the Army told
its pilots in August following extensive tests earlier this year.
But despite such warnings, the Army maintains there is no safety problem.
"None of the anomalies encountered during these tests resulted in
control movements causing flight safety critical conditions," the Black
Hawk's management office said in a videotaped briefing for the pilots.
A three-month investigation by Knight-Ridder has found:
* The Army grounded all UH-60s last year after one crashed near a
high-powered citizens' band transmitter in Alabama, killing all three
servicemen aboard. But Army aviation officials ordered the copters
back in the air 49 days later without telling pilots — or the Army's
top general — that the service's safety experts believed there was
a 50 percent chance of a similar accident within a year.
* In five mysterious accidents, the Black Hawks were flying below
1,000 feet when they suddenly dove straight into the ground, killing
everyone aboard. While the Army listed mechanical causes for three of
the crashes, senior Army investigators say they believe radio waves,
called electro-magnetic interference (EMI), were the real culprits. The
other two crashes are officially unsolved, although investigators
suspect EMI.
* While the Army minimizes the Black Hawk's vulnerability to radio
waves, the Navy, which also uses the aircraft, has taken a far different
approach. The Navy barred its first 14 Black Hawks — bought for
training purposes in 1982 — from coming within "a significant number of
miles" of radio towers for fear of accidents, a senior Navy engineer
said. The precise distance is classified. The Navy later demanded that
its future Black Hawks, known as Sea Hawks, be heavily shielded from
electronic interference. They can now buzz radio towers with impunity.
Officials as Sikorsky Aircraft Co., which builds the helicopters for
both services, said they deliver aircraft shielded to each service's
requirements, but declined to comment on the adequacy of the Army's
standards.
Because EMI leaves no "fingerprints," the Army has been unable or
unwilling to cite it as a cause of any of the 29 Black Hawk accidents
that have killed 48 servicemen since 1980. Shielding the Army Black
Hawks to Navy standards would be "very costly," Army officials said.
Many of the military officials, pilots, engineers and investigators
interviewed in the investigation of the Black Hawk agreed to speak only
on condition that their names would not be used. Most of these sources
are in sensitive positions and said they could lose their jobs or face
disciplinary action if they are identified.
But they speak with certainty about EMI's dangers.
"EMI is causing these aircraft to flip upside down and crash and kill
everybody on board," said one senior Army aviator. "There is a definite
problem with the Black Hawk and EMI — no question about it."
EMI is most deadly when it tinkers with the Black Hawk's movable rear
wing and its crucial hydraulic system. Both are operated by minute
electric signals that can be overwhelmed by outside electronic interference.
Related to me by my father:
My uncle, who operates a mobile comminucations shop (CB's, car
stereos, and such) was asked to install a cellular phone into a Pontiac
Fiero. When it came time to install the antenna, he wondered if it was
kosher to install it on the rear hood, where the engine is located. As I
recall, the antenna runs at 800 MHz.
He called Pontiac. After wading through a bit of bureaucracy, he
got a technician on the line. The tech said that installing a cellular
phone antenna in that position would cause bad things to happen to the
electronic fuel injection. He didn't specify what sort of bad things.
It seems to me that, if the electronic fuel injection were properly
shielded, this problem wouldn't exist. It also seems to me that proper
shielding is trivial. Am I missing something? Is Pontiac missing
something?
Leo L. Schwab
In the article "Computers Amplify Black Monday", _Science_,
30 October 1987, Volume 238, Number 4827, there is an interesting
discussion of the potential effects that computers had. The most
interesting parts were:
"Large scale, distributed computing systems have been proposed in
a wide variety of applications ... The automated stock market may
thus hold some important lessons for the future. Indeed, recent ...
research suggests that large distributed systems of this kind may be
governed by ... chaos --- which means that they may be inherently
unpredictable ..."
NYSE chairman Phelan warned that "... computerized trading
practices in general are a stabilizing influence only when the market
itself is relatively quiet. When things become unsettled, computerized
trading could all too easily become destabilizing."
The article goes on to quote Bernardo Huberman and Tad Hogg at
Xerox PARC, and their work on modeling "computational ecologies".
and...
"The momentum for further computerization on Wall Street is clearly
high. ... This momentum is leading Wall Street to delegate more and
more of its day-to-day decision making power to the computers ---
a prospect that many people find troubling. Of course, a
hypercomputerized Wall Street might not be so different from the
Wall Street of today. Brokers are already making $100 million
decisions on 60-second time scales, using nothing for input but
the flow of numbers on a computer screen. It is hard to imagine
that they are giving those decisions any deep thought, of
bringing any considered judgement to bear. What the prospect
does do, however, is to throw a spotlight on the kind of
economic models being used to program these computers. The
economic assumptions may be valid enough for normal times."
John L. King (UC Irvine) says "But it's like a nuclear power
plant — the emergency system is very important, even if you use
it only once a year." and "what Monday illustrates to me is just
how little we know."
These points make me worry more about the problems of software engineers who
write software without knowing the problem domain. And furthermore, even if
we/they know the domain, it may be controlled by "chaos", and may be
inherently unpredictable.
Bjorn N. Freeman-Benson
In RISKS-5.49 Bob Berger writes :
> I hope that the experience of a large network of computers doing something
> unplanned for such as accelerating the crash of the stock market will make
> the "Decision Makers" stand up and take notice! [...]
It appears that Bob has missed the "REAL" risk of this situation. The
automatic trading programs all behaved as expected and correctly within
their own environment. The problem is that none of these systems had
knowledge, or at least only severly limited knowledge, about their external
environment. The In this case we were dealing with the interaction of many
independent systems where these relationships were not fully understand
and/or planned for. The real risk is when system designers do not
understand the relationship between all of the various components that are
part of a real world environment. This has a direct impact on software
certification procedures for any system, because it is not acceptable to
certify the functionality of each piece of a system and then declare the
system correct.
Michael R. Wade, Spatial Data Analysis Lab, Virginia Tech
In RISKS 5.55 Geoff Lane writes about an operator overriding a check for
tape label mismatch causing his tape to be overwritten.
A similar thing happened to me when I was working with tapes on a CDC
Cyber. The installation handled transient tapes in much the same way,
except that there is no opportunity for operator intervention on a
label miscompare. There is, however, nothing preventing two or more
tapes being in the transient library with the same VSN (but different
IDs). Furthermore, there is nothing in the operating system preventing
two labelled tapes being mounted at the same time with identical VSNs,
and the system will assign the one on the lower-numbered drive to the
first job that wants it, even if it wanted the other tape, and even if
it specified the ID. If the tape is ANSI-labelled, the system does not
ask the operator for the ID written on the paper label.
In my case, I ran a three-tape archive for a friend, and when later I
tried to retrieve something from the first (identical) tape, the tape
was blank but had the right label. In this case it looked like the tape
was re-initialized by someone else who thought they were putting labels
on their own tape. Again, nothing prevents a user from entering a tape
into the transient library and re- initializing it with a different
VSN, possibly one of another tape already in the library, creating
another opportunity for mounting the wrong tape.
On an even less-related note, I once noticed on a 4.2bsd system that
the root file system was 105% full. The cause was a plain file of two
megabytes called /dev/nmrt0. Some poor user thought his thesis work
was on the tape he was carrying across country....
LERMINATING PREVIOUS SESSION. PQEASE RETRY.
[(Sic!) I could not resist leaving that line in. PGN]
Before David Honig concludes that he can safely forget about those phantom UCI parking tickets, he should probably read Gordon Dickson's classic SF story, "Computers Don't Argue". In this story, a book club member who doesn't want to pay for an unordered copy of "Kidnapped," by Robert Louis Stevenson is arrested for kidnapping R. L. Stevenson (a capital offense, since the victim is dead). This story might have had a happy ending, except, well, computers don't argue. Actually, it might be irresponsible of me to make a joke of this or treat it as Science Fiction. It's worth noting that this phantom warrant might lie around various disk drives for a long time, and any traffic cop who stops Mr. Honig for a broken taillight has no way knowing that the positive warrant check is the result of a software error. While not that serious an offense, unpaid tickets *are* cause for immediate arrest — and bail bondsmen are not anxious to cover legal amnesiacs. Isaac Rabinovitch
You may be aware that recently a national ID card scheme in Australia was defeated (unfortunately only on a technicality). However, as a result, the Senate Standing Committee on Constitutional Affairs is holding an inquiry into the whole mess. Written submissions close on December 11, public hearings will begin next February, and the report is required by May. Submissions are invited from all and sundry. I enclose the terms of reference for your interest. - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - TERMS OF REFERENCE (a) the provisions of the Australia Card Bill 1986 considered in the light of the reports of the Joint Select Committee on the Australia Card and of the Scrutiny of Bills Committee; (b) the feasibility of any proposed national identity system operating in the event of a failure of any one or more States to co-operate on the establishment of a births, deaths and marriages register; (c) the extent to which new or updated computer systems and recent crackdown campaigns on welfare cheating and tax avoidance and evasion have obviated the need for a national identity system; (d) the appropriate responses which should be made to the recommendations contained in the various Australian Federal Police reports on fraud against the Commonwealth and the Report of the Review of Systems for Dealing with Fraud of the Commonwealth; (e) the direct cost to the private sector in establishing and maintaining any such system; (f) the capacity of the proposed Data Protection Agency to adequately safeguard and protect the privacy of the individual and to control unauthorized use of any proposed national identity card and/or individual identification numbers by commercial organizations such as credit insurance companies and unincorporated associations and clubs; (g) the desirability, timing and nature of comprehensive privacy legislation in Australia in the light of concerns raised in the debate over the proposed Australia Card legislation; (h) the extent to which any proposed system should accord with OECD guidelines on the Protection of Privacy and Transborder Flows of Personal Data (1981); (i) the extent of personal data held on Australian citizens by Government Departments and Agencies and by private sector agencies, its level of accuracy, access to it and its cross-referencing within the Government sector; (j) the security of data already held by Government Departments and Agencies; (k) the physical security of dedicated land lines and other data transmission facilities currently in use or proposed; (l) the appropriate range and level of penalties on individuals and other entities, which should be imposed for the improper use or release of personal data; (m) the evidence available from overseas as to the experience of other countries with identity card systems, including the taking of evidence from overseas expert witnesses; (n) the usefulness of any card and numbering system in achieving the objectives of reducing the extent of the cash economy, organized crime and large-scale tax evasion and welfare fraud; and (o) any matters relevant to the preceding. (Journals of the Senate, No. 12, dated 8 October 1987)
This message is quite a bit late — I got busy, and then waited until I
had time to catch up on Risks before answering.
My sincere apologies to the moderator for starting the recent barrage
of Unixalia. My original comment, which has perhaps receded into the
umbrageous recollections of RISKS Digests past, concerned the SILENT
truncation of a password to 8 characters on 4.3 BSD. I am overwhelmed
at the quantity and depth of discussion on the security of the modified
DES algorithm, the propensity of a Cray to zap Sun 3 passwords with a
laser, etc., all of which misses the original point (but is perhaps
interesting in its own right).
The PROBLEM is that a program to set passwords sets the password to
something other than its input, without warning the user. The RISK is
that the user might end up with a non-secure password as a result. I
have seen the same problem, exhibited by the (Massachusetts based)
BayBanks automated teller system. In that case it resulted in dollar
loss and a squabble between the bank and an innocent customer, when an
ATM card thief was easily able to guess a password (this occured some
time ago - one imagines that the problem has since been fixed). In my
case, the problem resulted in an account in an obscure corner of the
DoD internet that had a password which was easy to guess. The password
remained for a week or two, and I don't believe that the account was
penetrated (other than by me!).
We engineers have a tendency to allow our fascination with technical
solutions to distract us from the issue at hand: this is a true "risk."
The technical solution to the bug I mentioned is trivial — modify the
program that sets passwords to warn you when a password is being
truncated. Other interesting technical solutions have been presented
in this forum.
I echo PGN's recent comment that it is a poor user interface to a system's
security features that is often the easiest entry point to the penetrator,
rather than a deficiency in the system's operation.
- Geof Cooper
In RISKS-FORUM Digest Vol 5, Issue 55, Stephen Russell discusses a bug
in a student assignment submission system:
> ... It then invokes the second program, which is basically
> a setuid root file copy program. It needs to be setuid root, as it writes
> into a protected directory. The copy program is publicly executable, although
> (we believed) reasonably well hidden.
The directory has to be protected, of course, and the copy program has to be
setuid, but why to root? If the assignment directory is owned by a normal
user account, perhaps an account set up specifically for the class or
professor, then it is just as protected from casual snooping as a directory
owned by root. Then even if the security checks of the file copy program
are breached, the intruder can damage only files associated with the class.
This is bad news for the class, I suppose, but the system is protected.
George Kaplan Internet: gckaplan@sag2.ssl.berkeley.edu
UUCP: ...!ucbvax!ucbssl!sag2!gckaplan
in RISKS 5.52 John J. McMahon says: > ... Their immediate reaction was to take a large armored personel carrier > (APC) and park it on the missile silo... I'm very much impressed by this cool, clear, lateral thinking. (Or was this the solution in the Minuteman manual?) Surely there must be other examples of people averting `computer' disasters by unobvious mechanical means... Mike Bell UUCP: ...seismo!mcvax!ukc!camcon!mb Phone: +44 223 358855
Today I received a computer-generated junk letter that had three
view-through boxes in the envelope:
+------------------------------------------------------+
| Recepient |
| If your name appears in the box below, you have won! |
+------------------------------------------------------+
+------------------+ +---------------------------------+
| John Brink | | Benson |
| Recipient | | .... |
| Anne B. Meechan | | Seattle, WA 98115 |
| Cindy Lenorowitz | +---------------------------------+
+------------------+
And it said inside "The names herein have been computer selected from amoung
thousands without regard to gender or affiliation." Yeah, no kidding! And
without regard to their existence, too!
Bjorn N. Freeman-Benson
I read the following in the Minneapolis Tribune, Monday, 9 Nov 1987: Portable Computer Falls Out of Airlink Jet Oshkosh, WI (Associated Press) Usually a computer "crash" is caused by a malfunction in the machine. But when Ron Olstad's computer crashed last week, it really crashed. Olstad arrived in Oshkosh on a Northwest Airlink flight from Minneapolis about 3 p.m. Thursday and noticed that his portable computer was not among the luggage unloaded from the plane. At about the same time, Ronald Miller's neighbors found Olstad's 50-pound computer - or what was left of it - in Miller's back yard in Oshkosh. Robert Schoenfelder, Oshkosh manager for Northwest Airlink, said Saturday night that the port door of the airplane was open during the flight and that the computer fell out as the plane was making its final approach to Wittman Field. Schoenfelder said it is the first time that he knows of that a piece of luggage has fallen out of a plane of Northwest Airlink, which is a contract carrier for Northwest Airlines. He said Northwest Airlink replaced Olstad's computer. Miller's neighbors say they weren't startled when they heard a loud crash and saw papers flying around Miller's back yard. Two nearby elementary schools were letting out at the time and the neighbors thought it was just noisy students. It turned out to be Olstad's computer. "I noticed a branch had fallen and there were papers flying all over the back yard," said Adeline Heyer. "I didn't hear anything, but after looking a little closer I noticed the case." Miller had been gone and learned of the incident Friday. "There were papers scattered in the back yard and this big green thing," he said. The computer, which was in a canvas case, was destroyed. My first reaction upon reading this was to laugh. My second was to wonder if any parents in the neighborhood thought they should have prepared their children to live in the area surrounding an airport by issuing them crash helmets.
Please report problems with the web pages to the maintainer