Subject: RISKS DIGEST 11.85 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Saturday 8 June 1991 Volume 11 : Issue 85 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: DoD News Release on missed Scud intercept at Dhahran (Scott A. Norton) Thrust reversers (Mary Shafer) RISKS of Management Attitudes (Tim Steele) Company BBS eavesdropping (Andy Duane) Re: Government should have less access? (Michael L. Duerr, Martin Ewing) Re: Government listening to the airwaves (John Gilmore, Geoff Kuenning) EFFector Online 1.07: S.266 Loses First Round (Christopher Davis) Proposed Credit Reporting legislation (Mike Cepek) Caller-ID and Risks/Benefits of reusing commands (David Lesher) UUNET sending Usenet tapes to the FBI (Rick Adams) The Activated Active Badge Project (anonymous) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 11, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: 7 Jun 91 16:25:47 GMT From: norton@manta.nosc.mil (Lt Scott A. Norton, USN) Subject: DoD News Release on missed Scud intercept at Dhahran Here is the DoD News Release that provides some information on the failure of Patriot batteries to intercept the Scud missile that hit the Dhahran barracks. -Scott Norton [Quoted text follows] Assistant Secretary Of Defense, Public Affairs, Pentagon, Washington DC A/V 225-3886 (912)695-3886 - - - - - - - DEPARTMENT OF DEFENSE NEWS WEDNESDAY, JUNE 5, 1991 * * * * * * * * Department of Defense News Editor: Mr. Frank Falatko - - - - - - - - - - - - - - - MEMORANDUM FOR CORRESPONDENTS, WEDNESDAY JUNE 5, 1991 REPORT ISSUED ON SCUD MISSILE ATTACK The Department of the Army announced today the results of its review of the investigations pertaining to the Scud missile attack against Dhahran, Saudi Arabia, on February 25, 1991: That evening a Scud missile impacted into a warehouse used by U.S. Forces as a barracks in Dhahran, Saudi Arabia, killing 28 and -wounding 98 U. S. Army soldiers. Two investigations were initiated shortly after the attack. One focused on Patriot operations and the other on actions taken at the barracks that was attacked. The investigation of Patriot operations concluded that an inexact computer software calculation is the most likely explanation as to why the battery did not effectively detect or track the incoming Scud. A similar problem of this nature was first documented on February 20 after analysis of an earlier Scud engagement. The four days of continuous operation by the battery, caused by increased day and night Scud activity, are thought to have compounded this software problem. Updated software fixing this problem and containing other improvements arrived at the battery's location on February 26. The investigation of the barracks concluded that Scud attack procedures were properly followed. More specifically, upon warning of a potential Scud attack, soldiers had instructions to go inside or get under cover in either concrete bunkers or bomb shelters, if available, and to put on helmets and chemical protective gear. It was impossible to determine precisely how much warning time the soldiers ha but it appears that they were alerted approximately 30 seconds prior to the Scud's impact. Both U. S. and Saudi emergency medical response was timely. The investigation of Patriot operations was conducted in theater by officers from the 11th Air Defense Artillery Brigade. An independent technical review from the Patriot Project Office at Redstone Arsenal concurred with the findings of the investigation. Six Patriot batteries were located in the Al Jubayl-Dhahran- Bahrain area. Two were positioned to engage this Scud missile. One of these batteries was out of action for repair of a radar receiver. The remaining battery was operational and prepared to engage an incoming Scud missile. The operational battery was positioned to fire in the automatic mode against Scuds threatening an area surrounding the Dhahran air base. Scuds threatening outside of this protected area but within the Patriot's engagement capability could also have been engaged manually. The barracks was located in this manual engagement zone. Because the Scud was not effectively detected or tracked by the radar, engagement in the manual mode was precluded. The investigation reconstructed the circumstances of the Scud attack and evaluated the possibility of Patriot hardware, software, or operator error. Based on diagnostic checks conducted before and after the attack, hardware failure was ruled out. Operator error was also eliminated as a cause based on a review of Patriot crew procedures. The Army deeply regrets the loss of life and extends its sympathy to the families of those who died or were injured. ------------------------------ Date: Thu, 6 Jun 91 22:35:42 PDT From: Mary Shafer Subject: Thrust reversers (Sims, RISKS-11.84) Yes, they're still using these two Shuttle Training Aircraft (STA). One of them was here at Edwards last week, for rehearsal for the current mission. JSC will send one (or both, it varies) the day before the landing. They'll put it up before landing, to get the winds aloft for the subsonic portion of the approach and landing. >To simulate the shuttle's glidepath, you take a G-II up to altitude, ... I've flown a lifting body approach in a TF-104G Starfighter. Dirty up and pull the throttle back to flight idle (no reverser) and drop like an HL-10/rock/shuttle. From the backseat it's damn spectacular. I've seen video/film footage of inflight thrust reverser deployment for transport aircraft. This is required for FAA certification of civil transports. It's usually a somewhat boring bit of film, since nothing dramatic happens. All you really see is the reverser deploying, which is kind of cute for clamshell reversers. However, the YF-12 and the SR-71 exhibited a phenomenon known as the "unstart". Essentially the engine control system (I hesitate to refer to this as a computer) would get goofed and the inlet would swallow the shock. The airplane would yaw violently and lose 10,000 ft. One of our test pilots likened to it being broadsided by a train. The control system was modified and unstarts went away, much to everyone's relief. Mary Shafer shafer@skipper.dfrf.nasa.gov ames!skipper.dfrf.nasa.gov!shafer NASA Ames Dryden Flight Research Facility, Edwards, CA ------------------------------ Date: Sat, 8 Jun 91 15:05:53 BST From: tjfs@tadtec.uucp (Tim Steele) Subject: RISKS of Management Attitudes When I was working for a British computer company (and major defence contractor) ten years ago, I had an unfortunate experience. A friend came to me and said that he had discovered that it was possible to enter the on-line personnel database with *no* passwords from any terminal in the building. I found this difficult to believe, so he demonstrated this to me in a highly effective manner, retrieving data on several senior employees. The personnel records included fields for driving licence endorsements and confidential manager's assessments of the employee. I was stricken by conscience, and eventually decided to visit Personnel and explain what I had been shown without revealing my friend's name. I urged them to tighten up their security. Subsequently, Management decided it would be easier to discipline the guilty party than to add passwords to the personnel system. A hunt was started, and my friend was located on the grounds of above average intelligence and a propensity to work late (we all scrambled for the door at 5pm!). He was severely disciplined and threatened with dismissal. As you can imagine, I didn't feel too good about it... The thing that really annoys me is that it *was* a cheap solution... Another occasion when this came up was during my employment with a large American computer company some years later. I discovered that a hacker was probing our network, getting into workstations and then destroying them by the use of "rm -rf /" as super user. The penetration was usually achieved by logging in as the lp pseudo-user which had no password and had a normal Bourne shell, then exploiting the world-writable / directory. Both of these security holes were included in the Unix distribution produced by that company. I laid a trap for the hacker, and we eventually obtained water-tight evidence leading back to a terminal port in an office occupied by one employee. The evidence was submitted to senior management. We knew that the Company's written policy in such matters was to summarily dismiss the employee concerned, so we assumed the outcome was not in doubt. The management action taken was to ask the employee whether he was responsible for any malicious action. He was not confronted with the evidence. He denied any such action, and the matter was dropped. That company is connected to the Internet... Tim ------------------------------ Date: Fri, 7 Jun 91 9:08:23 PDT From: aduane@urbana.mcd.mot.com (Andy Duane) Subject: Company BBS eavesdropping In RISKS-11.80 (not 11.79 as previously cited), an anonymous poster tells of the chilling effects of people in his company discovering they were being electronically "eavesdropped" by personnel. In 11.83 there are some suggestions for how to deal with this. Well, I'd like to relate a "happy" story about BBS eavesdropping. My old company had a long-standing BBS called "graf" (short for "graffiti"). It was a mostly anonymous company-wide BBS that anyone could read or write to. Most engineers did both, and much of middle and upper management at least read it. This was pretty much an electronic suggestion box, although you'd be amazed at what discussions cropped up from time to time. The articles themselves were anonymous, although a central encrypted log was kept showing who wrote what. This log was maintained by "GRAF-man", who was *not* a manager of any type. The log was only to be used if a serious breach of law or policy was observed, and this almost never happened. All very nice indeed. Well, I moved to a new company, and brought the code to GRAF with me. When I arrived there, the personnel manager informed me that she thought it was a great idea, but only if I would remove from the code all traces of logging! She wanted to be sure that it was not possible to trace an author at all. This BBS was not only a great morale booster among the engineers, it provided a good way to let your superiors know what you thought without having to sign your name. Andrew L. Duane (JOT-7), Samsung Software America, One Corporate Dr., Andover, MA 01818 decvax!cg-atla!samsung!duane ------------------------------ Date: 7 Jun 91 18:31:20 GMT From: motcid!duerr@uunet.UU.NET (Michael L. Duerr) Subject: Re: Government should have less access? (Gilmore, RISKS-11.80) Remember, the risk here is of the government running open - loop with surveillance technology. Harassment is not protected by exclusionary rules. As for dossiers - by saying the magic words "National Security", the government can ignore Freedom of Information Act requests. You would never know that there is a dossier, only that you get audited every year, get thoroughly searched at customs every time, etc. Unless there are meaningful sunlight laws the technology should protect the citizens from the government. Current trends like [ constitutionally dubious] national security preemptions, censorship ( a la gulf war ), excessive fees for access to government information, new forms government employees must sign ensuring secrecy in all departments, etc. highlight a trend toward greater privacy for the government and less for citizens. Any invasive technology thus poses serious problems. Could it happen here? Well - would most people even notice if it was? ------------------------------ Date: Wed, 05 Jun 91 14:36:25 -0400 From: Martin Ewing Subject: data over radio (Gilmore, RISKS-11.80) But telephone traffic has gone "on the air" for a long time via microwave links. This is becoming less of a problem as optical fiber becomes more universal, but a classical activity of foreign embassies has been to set up eavesdropping equipment to intercept microwave traffic passing overhead, especially in Washington. There was (and is) no legal protection here, except that it has always been unlawful to divulge any communication you may have intercepted from such a common carrier circuit. At the risk of being flagged in Big Brother's computer, I wonder if there are publicly documented instances of microwave telephone or data transmissions being tapped for nefarious purposes, besides the embassy example. ------------------------------ Date: Fri, 7 Jun 91 01:41:42 PDT From: gnu@toad.com (John Gilmore) Subject: Re: Government listening to the airwaves (Florack, RISKS-11.83) > Let's please make sure that in your (IMHO, overblown) concern about government > monitoring we don't cripple the government's ability to enforce laws which > allow the day to day operations of telecommunications equipment to be smooth. Let's enable the microphone in every room (there's one in most rooms already -- in the telephone) so we don't cripple the government's ability to enforce laws which allow the day to day operations of society to be smooth. Why should your over-the-air conversations be any less private than those in your house, business, or car? > Many two-way services are content specific. There are specific channels for > just about every type of business on the business bands, for example. > How would you suggest that these be enforced without routine monitoring? How about allowing the "owners" of these bands to record conversations and provide them as evidence in a suit? Why should we pay the government to listen to every band, when the band's users are already listening and are even motivated to report and prosecute regular abusers? If special equipment is needed to track down the abusers, I'm sure that commercial services will be glad to do it -- some of them for a contingency fee that comes out of the proceeds of a successful suit. > Free speech is not the issue in situations like what I suggest. FOr example, > the business bands, let's say a taxicab channel, for example, is not the place > to be discussing political thinking. Telegraphy was not considered a medium for free speech -- and the laws and regulations around it definitely and obviously didn't have the First Amendment in mind -- because who would pay $5/word for free speech in the days of penny newspapers? But those regs became the precedent for telephone regulation, and later radio and TV, and later cable. Who would suspect that the Fairness Doctrine, or Federal regulation of the content of signals traveling in local coaxial cables, would come out of prohibitions on use of private code books in international telegraphy? [We're having to fight and pray that the same precedents are not upheld in cases involving computer communications, or we lose our speech rights in that medium too.] See Ithiel de Sola Pool's great book _Technologies of Freedom_. > The issue as I say, is not free speech, > but rather, the effective and efficient use of the bandwidth.... a matter for > the FCC to determine, certainly. It seems to me that effective and efficient use of the bandwidth would be for the *users* to determine. The FCC didn't think ASCII was effective use of bandwidth in the amateur radio service until the late '70's -- transmit in Baudot, or lose your license! FCC's concern is *politics*; users are the ones who want to have high bandwidth and high reliability of communications. The Bush Administration thinks so highly of FCC's ability to allocate spectrum, that it wants to *auction* 200MHz previously reserved for the government, rather than have FCC parcel it out politically. ------------------------------ Date: Thu, 6 Jun 91 03:44:15 PDT From: desint!geoff@uunet.UU.NET (Geoff Kuenning) Subject: Re: Listening? (Eric Florack, RISKS-11.83) > Many two-way services are content specific. There are specific channels for > just about every type of business on the business bands, for example. > How would you suggest that these be enforced without routine monitoring? Well, what sort of leaps (or perhaps pole-vaults) to mind is that the FCC could wait for a complaint, and then monitor to verify the complaint. Note that this is not "routine monitoring." Most of the business bands (e.g., taxicabs) are not going to suffer too severely in the meantime, relative to the U.S.'s historical and constitutional predilection for freedom and restricted government even at the expense of inefficiency. Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff ------------------------------ Date: Fri, 7 Jun 91 17:42:51 -0400 From: ckd@eff.org (Christopher Davis) Subject: EFFector Online 1.07: S.266 Loses First Round EFFector Online|EFFector Online|EFFector Online|EFFector Online EFFector Online|EFFector Online|EFFector Online|EFFector Online Volume 1 Issue:1.07 Friday June 14, 1991 SENATE ANTI-ENCRYPTION BILL WITHDRAWN WILL BE REPLACED BY A NEW OMNIBUS CRIME BILL -- S.1241 SENSE OF CONGRESS LANGUAGE RESTRICTING ENCRYPTION REMOVED When Senate Bill 266 was proposed, some of its provisions would have restricted the rights of individuals to secure online communications through the use of encryption programs. The specific language was: "It is the sense of Congress that providers of electronic communications services and manufacturers of electronic communications service equipment shall ensure that communications systems permit the government to obtain the plain text contents of voice, data, and other communications when appropriately authorized by law." Let stand, this language would have a chilling effect on encryption. It would inevitably compromise individual privacy in telecommunications. The Electronic Frontier Foundation and several other groups determined to oppose this provision. In the last issue of EFFector Online, we reported we would register our opposition to this clause. In this case, Senator Patrick Leahy (D. Vermont), who chairs the sub-committee on Technology and the Law --a sub-set of the Senate Judiciary Committee-- was the key to this issue. This week the EFF met with Leahy's staff to present our reasons for the removal of the language dealing with encryption. Today, we were informed that the encryption clause has been eliminated from the new crime bill which replaced the bill originally known as S.266. In addition, Leahy's sub-committee on Technology and the Law has undertaken to study the issues of encryption and telecommunications technology. To continue this dialogue, Computer Professionals for Social Responsibility, the Electronic Frontier Foundation, and RSA will be holding an invitational workshop on privacy and encryption in Washington later this month. Following the workshop, a press conference will be held to announce a set of policy recommendations on cryptography. The conference will take place on Monday at 2:00 at the National Press Club (14th & Pennsylvania Avenue N.W.). All interested parties are invited to attend. -==--==--==-<>-==--==--==- Please direct all mail regarding EFFector Online to: editors@eff.org ------------------------------ Date: Fri, 07 Jun 1991 21:44:03 CDT From: "Mike Cepek, MGI" Subject: Proposed Credit Reporting legislation >From a 7-Jun-91 Associated Press article (c/o Minneapolis Star Tribune): "Four house members [...] have proposed legislation to update the Fair Credit Reporting Act of 1970. "Among their proposals are providing consumers with a free copy of their credit report on request, requiring prompt correction of errors [isn't this already required?], requiring credit bureaus to notify consumers after adverse information is placed on their record and prohibiting the release of information for marketing lists unless consumers consent." The article goes on and on about the tribulations of two men after credit agencies `merged' their records with others with the same name (middle _initials_ were used, one dropped a Jr.). One lost his job because his Equifax record was `updated' to indicate `his' guilty plea to a charge of attempting to purchase cocaine [excuse me, what is this doing on a _credit report_?]. "Equifax [...] admitted making a mistake, but said it promptly corrected it." The second man had bill collectors after him about a $1,776 Discover card bill -- of course he doesn't have a Discover card. "Even though it took nine months to clear his record [...] he [said] he feels lucky. [...] `If this had happened four months ago, I probably would still be living in an apartment,' he said." (He bought a house and car prior to the problem.) This happened to me. It only took me _two months_ to get it fixed. No, those 60+ and 90+ payments records aren't mine, I said. No, I've never lived in North Dakota ("my" former address). No, my spouse's name isn't Kathy (my wife gave me the evil eye about that one). And come on, wake up you guys, my middle initial is not `J'! (they did know that). While I have a personal vendetta to fulfill by assisting this potential legislation, I ask that other U.S. RISKS readers get involved. While I don't have all the details, I would think that any RISKS regular would strongly support those bits I have mentioned. -- Michael *K* Cepek ------------------------------ Date: Sat, 8 Jun 91 8:41:12 EDT From: David Lesher Subject: Caller-ID and Risks/Benefits of reusing commands After a long and bitter fight between Bell South and the opposition - spearheaded by the {state, local, federal} law enforcement community and the domestic violence groups - the PSC approved Caller-ID in Florida. They mandated universal free per-call blocking, activated by *67, and per-line blocking for some LE offices/shelters. (Bell wanted no per-line, and per-call limited to a narrow list of LE offices.) But it sounds as if Bell South still wants her pound of salt. I hear they've ALSO set up *67 for a per-call UNBLOCK on a blocked line. So the cop (who has NO way of confirming that the line she's using is/isn't line-blocked) dials the same *67 she uses at home, and guess what. The result (besides an appeal) is that I hear no one is planning to order the per-line block. Hmmmm. wb8foz@mthvax.cs.miami.edu (305) 255-RTFM ------------------------------ Date: Fri, 7 Jun 91 17:12:24 -0400 From: rick@uunet.uu.net (Rick Adams) Subject: UUNET sending Usenet tapes to the FBI Uunet has revealed that they have sold compiled Usenet traffic on tape to the FBI. FCC men and telco security [people] are known to read the Telecom Digest. God only knows who reads RISKS. "revealed" is hardly the right word. UUNET sends news to over 800 organizations. Thats never been a secret. We also send news out via tape. There are two reasons to get a tape. 1) Phone calls are too expensive (E.g. Mayalsia or Indonesia) or 2) Site security does not allow modems. In the case of the now legendary "UUNET sending compiled usenet traffic to the FBI": 1) We gave them a news feed just like any other customer. 2) This was the Violent Crime group at Quantico. They're the behavioral science folks who track the serial killers around the USA. (If you saw "Silence of the Lambs", that was the VICAP group at Quantico). These guys are sharp, fully professional and completely ethical. One of them actively participates with the CERT group. 3) They got Usenet feeds for the same reason everybody else does. -- Once you throw away the 98% crap, you're usually left with some really useful source programs and technical information. (The FBI employs UNIX wizards too!) 4) We stopped sending the tapes years ago, when they became concerned about possibly picking up a virus from one of the programs on the tapes. 5) They gave me a nifty official FBI coffee mug which is now sitting on my desk. So yes, UUNET has sold USENET tapes to the FBI. Yes, we were paid for this nefarious service (one coffee mug). Yes, the conspiracy freaks have had a field day ever since. The time to start worrying is when the FBI starts getting news and pretends to be "Quantico Computing Systems" or something. Not when they do it under their own name. ---rick p.s. how come no one noticed the uucp site "stu", which is at the FBI headquarters building in Washington, DC. (Soon to be West Virginia due to the most outrageous example of porkbarreling by Sen. Byrd I've seen in years) p.p.s I know that NSA and CIA employees read Usenet and have for (But I don't *think* we're sending it to them...) ------------------------------ Date: Fri, 7 Jun 91 11:45:28 xxx From: Anonymous Subject: The Activated Active Badge Project Place: Pod 26 Commons Time: 10:30am, Friday, June 7 Title: The Activated Active Badge Project Speaker: Nicolas Graube Cambridge EuroPARC Olivetti's Active Badge are small devices capable of emitting at regular intervals an infra-red signal which is in turn received by captors placed in every offices, corridors and public places at EuroPARC. Introducing these badges is not an easy task as they are immediately perceived as tracking and logging devices and thus subject to possible misused. I will first reviewed the BirdDog experiment conducted at EuroPARC whose goal was to introduce active badges and study users reactions. Then by following lessons learnt from this experiment I will introduced a distributed architecture for badges and a more general usage of these devices. Within the Activated Active Badge project, badges are no longer considered as tracking devices but are viewed as contextual multi-functional remote controllers. The main goal of the project is to give control to the user both in the specification of its badge semantics and in the becoming of data generated by its badge. I will introduce a simple rule based language enabling this specification. However because the description of the badge semantics using this language is very much a programming exercise, I designed a graphical interface enabling the iconic description of badge activity. I will conclude by listing possible future extensions and showing a video of interfaces designed for controlling Active Badges. ------------------------------ End of RISKS-FORUM Digest 11.85 ************************