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: firstname.lastname@example.org 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