Subject: RISKS DIGEST 15.76 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 18 April 1994 Volume 15 : Issue 76 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** ***** INCLUDES Mosaic INFO for RISKS. Contents: "Friendly Fire" --- U.S. F-15s take out U.S. Black Hawks (PGN) The Green-Card Flap Data-storage technique provides copy protection (Meine van der Meulen) Yet another example of software modification risks (Jim Dukelow) Re: Risks ... to the quality of science [randomness] (Steen Hansen) MIT student arrested for BBS used for pirate software (Fredrick B. Cohen) Credit-Card Fraud (Greg Philmon) NII and the US Card (Bill Murray) Reckless Baby Bell Marketing (Alan Miller) Re: P.R. China Computer Security Rules (Tom Albertson, Dan Sorenson) Delayed Dial Tone causes unintentional 911 calls (Chonoles Michael Jesse) Information resource (Michael Enlow) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Mon, 18 Apr 94 14:51:28 PDT From: "Peter G. Neumann" Subject: "Friendly Fire" --- U.S. F-15s take out U.S. Black Hawks [This item may be old news now, but is included for the archives.] Despite elaborate precautions designed to prevent such an occurrence, two American F-15C fighter planes shot down two U.S. Army UH-60 Black Hawk helicopters in the no-fly zone over northern Iraq on 14 Apr 1994, in broad daylight, in an area that had been devoid of Iraqi aircraft for many months. One Sidewinder heat-seeking missile and one Amraam radar-guided missile were fired. The fighters were operating under the communication control of an AWACS plane, which was the first to detect the helicopters, and instructed the F-15s to check the situation out. The helicopters were carrying U.S., British, French and Turkish officers from the U.N. office in Zakho, in northern Iraq, and were heading eastward for a meeting with Kurdish leaders in Salahaddin. Both towns are close to the Turkish border, well north of the 26th parallel that delimits the no-fly zone. All 26 aboard were killed. Both helicopter pilots apparently failed to perform the routine operation of notifying the AWACS plane after their last takeoff. Both helicopters apparently failed to respond to the Identification: Friend or Foe (IFF) requests from the fighters. Both fighter pilots apparently did not try voice communications. A visual flyby apparently misidentified the clearly marked ("U.N.") planes as Iranian MI-24s. Furthermore, a briefing had apparently been held the day before for the appropriate personnel of all of those aircraft (F-15s, UH-60s, and AWACS). There was speculation as to whether the pilots of both helicopters might have neglected to turn on their transponders, or whether the frequencies were set incorrectly, or whether both transponders failed (or perhaps some hybrid scenario). There was speculation that the fighter pilots did not try all three of the IFF modes available to them. There was also speculation that the Black Hawks may have visually resembled Russian helicopters because they were carrying extra external fuel tanks. But the AWACS plane personnel should have been aware of the entire operation, because they were acting as battlefield coordinators. Perhaps someone panicked. An unidentified senior Pentagon offical was quoted as asking "What was the hurry to shoot them down?" [Sources: various press reports in The New York Times and other papers, 15 Apr 1994 and 18 Apr 1994.] "Friendly fire" (also called fratricide, amicicide, and "misadventure") is not uncommon. An item by Rick Atkinson in The Washington Post (15 Apr 1994) noted that 24 percent of the Americans killed in action -- 35 out of 146 -- in the Persian Gulf war were killed by U.S. forces. Also, 15 percent of those wounded -- 72 out of 467 -- were similarly victimized. RISKS noted earlier the British Warrior armored vehicles that, mistaken for Iraqi T-55 tanks, were zapped by U.S. Maverick missiles, killing 9 men and wounding 11 others. Atkinson's article noted that this is an old problem, citing a Confederate sentry who shot his commander, Stonewall Jackson, in 1863, during the Civil War; an allied bomber that bombed the 30th Infantry Division after the invasion of Normandy in July 1944; and a confused bomber pilot who killed 42 U.S. paratroopers and wounded 45 in the November 1967 battle of Hill 875 in Vietnam. The old adage was never more appropriate: With friends like this, who needs enemies? The Black Hawk incident also brings back memories of the Soviet shootdown of the Korean KAL 007 flight and the Vincennes' shootdown of an Iranian Airbus. ------------------------------ Date: Mon, 18 Apr 94 15:12:17 PDT From: "Peter G. Neumann" Subject: The Green-Card Flap RISKS received a huge amount of mail relating to the husband-and-wife Phoenix immigration-law-firm, Canter & Siegel. Offering their legal services, they posted an advertisement on 5000 newsgroups, and gave information on a forthcoming lottery that will give out 55,000 green cards (granting permanent residency in the United States). C&S received at least 30,000 responses, mostly protesting their use of the Internet for advertising. Internet Direct suspended the C&S account for violation of the customer service agreement. I.D. had to put up with the thousands of pieces of objections. [This gives a new meaning to OBJECT-oriented E-mail.] C&S threatened to sue for I.D. for $250,000 for the lost responses. At least one site crashed repeatedly because of mail saturation. This reminds me once again of all the varied problems that I have with the fly-by-night it's-not-quite-the-Internet providers. One of them rejects mail after you hit your quota of external mail for the month. Some include the entire mailing list on each RISKS mailing, as noted earlier. Many do not permit FTP, but offer thousands of users the opportunity to invoke the almost-costfree availability of my pro-bono but not timefree services. Is regulation an answer? I shudder at the thought. I cannot begin to summarize the RISKS mail on this subject, and certainly would risk losing most of our subscribers if I ran the whole collection. The issues include the usual stuff about whether the no-advertising policy even exists, whether it is a per-newsgroup question or an Internet policy question, who actually controls the Internet, and all those topics familiar to RISKS folks. Perhaps we are waiting in expectation of the ultimate scam from New Haven, which might be considered a violation of Con-netiquette. ------------------------------ Date: Thu, 14 Apr 1994 13:26 +0100 (MET) From: MEULEN@tno.nl Subject: Data-storage technique provides copy protection Data storage technique provides copy protection Summarized and translated from "Intermediair", 1 April 1994, Vol. 30, Nr. 13, p. 35. Universities of Plymouth (in the U.K.) and Washington DC developed a technique to write five times as much information on magnetic media as floppy discs or bank cards. The magnetic layer is composed of small magnetic particles. Every bit is "remembered" by polarising several thousands of them in the same direction. This is done to overcome noise, due to the random orientation of the particles. The new technique only uses a fifth of the number of particles used in conventional techniques. It reads the information on the medium directly after writing it. By comparing the real magnetisation with the expected one, a chip determines the deviations in the medium. Based on that, information about these deviations is also written on the medium. Later, this enables flawless read out. An extra feature of this technique is that the information about the deviations is unique for every medium, comparable to a fingerprint. This means that when a bank cheques this fingerprint, it can detect fraud copies of bank cards. Meine van der Meulen TNO-Industrial Safety Department meulen@tno.nl ------------------------------ Date: Fri, 15 Apr 1994 13:16 -0800 (PST) From: js_dukelow@gate.pnl.gov Subject: Yet another example of software modification risks The following is a slightly edited version of a report from the latest issue of the Department of Energy Operating Experience Weekly Summary, which is a vehicle for rapid dissemination to other DOE organizations and contractors of occurrences at DOE facilities. "On January 17, 1994, the earthquake in Southern California caused widespread power outages in the western portion of the United States, and commercial power was lost at a DOE chemical processing facility. When commercial power was lost, a standby diesel generator automatically started and supplied power to critical loads. During a power transient caused by starting a large load on the diesel generator, four electric motors dropped off line and did not respond to a start command even though individual controllers indicated a ready-to-start condition. Facility personnel had to completely de-energize and then re-energize the motor controllers before the motors could be re-started. "After commercial power was restored, facility personnel determined that the porblem could not be duplicated for partially loaded generator conditions or with commercial power supplying the standby motor control center. Investigators determined that all the affected motors were connected to the same standby motor control center which was equipped with new digital motor protectors. Facility personnel developed a series of test procedures to determine the cause of the problem. After extensive testing, they determined that the motor protectors developed a software lockup after a power transient. During a simulation of the loss of commercial power, investigators determined that there was a correlation between voltage swings caused by starting a large load on the standby generator and the software lockup of the motor protector. The motor protector lockup resulted in the motor tripping off and not restarting until control power was removed and re-applied. "Facility personnel contacted the motor protector vendor with the results of the tests conducted at the facility. Vendor personnel confirmed the test results and reported that they had isolated the problem to specific units with firmware version F3, introduced in the fourth quarter of 1991. The vendor reported that units manufactured from 1987 through the third quarter of 1991 were not affected. "The vendor also reported that the units operated properly if the control voltage is maintained within plus or minus ten per cent of nominal voltage. If the control voltage surges beyond this range, the motor protector may trip the motor and require a power down to reset itself. The vendor offered to modify the affected units to eliminate the power reset after a voltage surge. "DOE facility personnel are advised to inspect their facilities for the suspect motor protector and take appropriate corrective actions." The risk associated with this event is that a software modification in 1991 rendered the standby electrical power system partially unable to fulfill its safety function. The root cause of this situation was that software engineer(s) involved in this modification (which was perhaps the initial digitally-controlled version of this component) were not fully aware of the actual operating environment (in this case, voltage swings greater that +/- 10% when the standby power system was doing what it was designed to do) of the digitally-controlled component. Jim Dukelow Battelle Pacific Northwest Laboratories js_dukelow@pnl.gov ------------------------------ Date: Thu, 14 Apr 94 08:09:46 -0400 From: Steen Hansen Subject: Re: Risks ... to the quality of science (Ruderman, RISKS-15.75) Some years ago I upgraded the operating system of a minicomputer. A few weeks later a faculty member became very upset: his research results had changed. Apparently the upgrade changed the random-number generator, which made his statistical programs give a different result. He demanded the original generator be put back in again. Steen Hansen, Computer Specialist, Ohio State University hansen+@osu.edu (614) 292-9317 (Stores/Food: Tue/Thu/Fri) (614) 292-5174 (Dentistry: Mon/Wed) ------------------------------ Date: Fri, 15 Apr 94 17:11:42 PDT From: Fredrick B. Cohen Subject: MIT student arrested for BBS used for pirate software An MIT student was arrested today for having a BBS at the school that was used by the participants to store and fetch commercial software. This one made the national news because of the promenance of the institution and the information superhypeway, but this sort of arrest has been going on for years in the "hacker" bulleting boards of the US. There is now a substantial history of these operators being convicted, but I have to question whether MIT should be arrested for allowing the BBS to reside on its computers. After all, if the BBS superuser can be arrested for unknowingly having the software on their BBS, why can't the institution be arrested as well? But the issue goes far deeper than this. At its core, we have the multitudes of people trying to tell us that the information superHW should have public access points and public spaces, but what happens when a public space is used for crime? The criminal is not arrested; instead, the person who provided the space is arrested. If we are to have public space on our info superHW, we had better stop arresting those who provide it for the crimes perpetrated in it. Otherwise, there will be a chilling effect on those who would provide it. How does this relate to RISKS? It should be obvious. If you have a party, and someone who attends commits a crime, you may be sent to jail for it. No precedent? Huh! If someone is drinking at your house or bar, and you fail to prevent them, and they drive away and get in an accident, you may be liable. I anxiously await your responses on the policy issues at play here. FC ------------------------------ Date: Thu, 14 Apr 1994 05:50:38 -0700 From: philmon@netcom.com (Greg Philmon) Subject: Credit-Card Fraud A friend recently applied for a credit card from a major issuer. Later he received a call from the bank informing him that his card was in a batch that was stolen somewhere along the delivery route. Over $4000 had been charged to his card in a 24 hour period. This was once quite common. However, most card issuers now use an automated system to "activate" the card. Usually it involves dialing an 800 number and entering some "secret" information (e.g. your birth date, ssn, etc). As it turns out, my friend's wife had received a phone call from someone claiming to work for the issuer. He said that they wanted to verify his application and asked for the his full name and SSN, which she gave. The automated authorization system of this issuer asks for the last four digits of your SSN. I'm really curious what sort of success rate was achieved by the thieves. Did they get fifty percent of the card owners to give their SSNs? More? Greg Philmon | philmon@netcom.com | CIS: 71161,3445 | MCI: 588-5358 ------------------------------ Date: Sat, 16 Apr 94 16:06 EDT From: WHMurray@DOCKMASTER.NCSC.MIL Subject: NII and the US Card Last week in the security track of the CardTech/SecureTech Conference, I heard a presentation by a representative of the U.S. Postal Service on the "US Card." This is a piece of the national information infrastructure intended to mediate all government services to and controls over the citizen. It will contain health care data, financial data, tax data, and identity data. It will contain a private key (digital signatures only), a PIN, and other identifying data. (While emphasizing that "open to new applications" was a requirement of the system, he was silent on arrest record, voter registration, gender preference, and previous condition of servitude.) Use of the card will be "voluntary." The government is doing this for us because it will enable them to give us better service, because the citizens require "one card," and to protect us from the "twenty million 'little brothers'" that we now recognize as the "real threat to our privacy." (He did not claim that this would protect us from terrorists, child molestors, drug dealers, or religious cults.) (All of this was delivered with a perfectly straight face and without challenge from the audience.) Of course if we do not like it, we can do away with it, right? The official stated that the Postal Service is prepared to issue a ahundred million of these cards within months of getting the go ahead. Along with the net, "voluntary" fingerprinting of the poor, CLIPPER, and the FBI's digital telephony initiative, what more could any citizen, not to say government, ask for? Law and order is just around the corner. Aren't you glad to hear that Orwell had it all wrong? William Hugh Murray, Information System Security, 49 Locust Avenue, Suite 104 New Canaan, CT 06840 1-0-ATT-0-700-WMURRAY; WHMurray@DOCKMASTER.NCSC.MIL ------------------------------ Date: Thu, 14 Apr 1994 11:04:55 -0500 (CDT) From: millera@mcs.com (Alan Miller) Subject: Reckless Baby Bell Marketing The following is most of a letter I sent to my local Baby Bell recently after receiving a marketing letter aimed at increasing calling card use. I think the risks of the mailing are fairly obvious from the letter... ajm I simply wanted to inform you that I was disturbed to find in my mail an unexpected letter from you that contained my Ameritech Calling Card PIN. My objections to this letter are as follows: 1) Since I was not expecting the letter, if it had been removed from my mailbox or the U.S. Mail before I received it I would have had no way of knowing that something was wrong until I got my next phone bill (complete with calls I hadn't made). 2) Increasing the possibility of delivery problems, the address on the envelope was, if not wrong, at least very nonstandard. In particular, it had two different forms of the town name, both on separate lines. If something this easy to catch made it through processing (presumably for many letters), what other errors might do the same? My monthly phone bill is properly addressed. 3) [Given a name and address, anyone with reason (PIN possession) can get my phone number] 4) [I can call customer service and get a new PIN assigned if necessary] 5) Finally, the presence of my PIN on the letter is not necessary on what is obviously a letter intended to increase awareness of calling cards. A note that I could contact Customer Service would have served just as well, without any of the security risks. Since card number theft is a serious and reportedly increasing problem, I am surprised to see Ameritech sending mailings that include information that consumers are told to guard carefully. If this mailing does result in an increase in calling card fraud, is Ameritech intending to absorb all fraudulent charges resulting from the careless distribution of PINs? The letter also makes me wonder about the security of my account with Ameritech. How simple would it be for someone looking for the ability to make a few free phone calls to simply look up and write down a few number+PIN combinations? ------------------------------ Date: Wed, 13 Apr 94 09:40:10 PST From: Tom Albertson Subject: Re: P.R. China Computer Security Rules Our contacts with the PRC government say that these rules do not exist. While this may be only a denial of something still in the works, its quite possible these are the work of someone with a regional axe to grind. Would you be willing to put me in touch with the anonymous poster, or would you debunk this on your own? If the rules are not legitimate, I don't think it was correct to post without some corraboration (I thought the unwritten rules of journalism called for two reliable sources for unsubstantiated materials?) Tom Albertson tomalb@microsoft.com PH 206-936-6764 ------------------------------ Date: 2 Apr 94 07:32:12 GMT From: viking@iastate.edu (Dan Sorenson) Subject: Re: P.R. China Computer Security Rules Note: this is somewhat political in nature, but I believe the RISKS are known to all in any position of responsibility or power. China opens the "Golden Bridge" to the Internet, and I see China still writes laws like the following: >Article 2. The computer information systems referred to in these regulations >are man-machine systems, composed of computers and their allied and >peripheral equipment and facilities (including networks), that collect, >process, store, transmit, and retrieve information according to prescribed >goals and rules of application. And in all likelihood this law would cover a supermarket scanner and cash register. I'm not surprised. Read any bill before Congress here in the USA and you will find a similar lack of understanding, broadness of definition, and lack of detail. Perhaps a better example shows up daily in the newsgroups rec.guns and talk.politics.guns, where laws as passed are picked at and it is generally determined that the law outlaws anything not specifically mentioned as exempt. The RISK? When people write the rules we have to live by, often times the spirit of the rule is lost in the letter, and the RISK of abuse is increased. One has to wonder at some of the latest anti-discrimination laws that wouldn't allow, say, a trucking company to not hire an applicant in an iron lung. I'm sure you can see your own pet versions of laws gone awry by creative interpretation. Finally, we're left with the axiom "You can't make it foolproof because fools are so clever." I submit that fools, lawyers, and government share this same affliction, and if we're not careful we shall as well, no matter our level of power over others. * Dan Sorenson, DoD 1066 viking@iastate.edu z1dan@exnet.iastate.edu * ------------------------------ Date: Fri, 1 Apr 94 17:49:08 EST From: chonoles@acc1.acc.vf.ge.com (Chonoles Michael Jesse) Subject: Delayed Dial Tone causes unintentional 911 calls Mostly, the problems with telephone numbers in the form x91-1xxx is the possibility that the first digit was ignored because of a delayed dial-tone. If the exchange is busy, and there are many people calling, the exchange may not have enough "digit registers" to allocate. Then there is a delay before the dial-tone appears. [Similar to what happened with the rock-concert ticket giveaway and on Mother's day, etc.]. Since most callers often don't listen for the dial-tone and dial anyway, dialing a number in the form of x91-1xxx might get them 911. As the number of central office codes (COCs), (the first three digits of a 7-digit number) is used within an area code increases, then these x91-1xxx numbers need to be allocated. The central offices that handle the x91 COCs need to have extra "digit registers' to lessen the chance for this problem. Michael Jesse Chonoles chonoles@acc.vf.ge.com mjc@eniac.seas.upenn.edu [This is another variation on an old problem addressed in many past issues of RISKS. PGN] ------------------------------ Date: Sun, 17 Apr 1994 21:48:54 -0700 From: Mike Crawford Subject: Seeking lit ref: we trust calculators over ourselves I seek a literature reference. The usual methods have failed so far - perhaps someone can give me even an author, more precise subject or partial title words? I will persist by looking up the references in papers referring to student use of calculators, but maybe this will ring a bell with you? There was a study done, perhaps in the seventies, of the human tendency to trust machines rather than our own judgement. Subjects were given calculators, and pages of simple arithmetic problems. The calculators were wedged so that they gave incorrect answers sometimes. Even though the problems were simple enough that the subjects could figure them out in their heads, the study showed that people will trust the machine even though our own judgment tells us that the machine is wrong. I want to use this as a reference in a paper I am writing on computer network security, and another I am writing about why high-aenergy physicists should not be so trusting of their results if they have been subjected to extensive processing by complex, and poorly understood computer programs. Thus, network administrators trust security software even when security experts tell them it is easily penetrable, and physicists trust the results of their calculations even when software experts tell them that their software is bogus. ;-) (C'est Moi! My own advisor does not believe me when I tell him the results of my own work are wrong. After all, they _were_ calculated on a computer!) Author of the Word Services Apple Event Suite. Mike Crawford crawford@scipp.ucsc.edu Free Mac Source Code: ftp sumex-aim.stanford.edu | get /info-mac/dev/src/writeswell-jr-102-c.hqx ------------------------------ Date: Wed, 13 Apr 94 00:26:45 -0700 From: m_enlow@enlow.com (Michael Enlow) Subject: Information resource We wanted to let you know about some great info we are making freely available on the Internet. My name is Michael Enlow. I am a retired private/legal investigator and author of several books regarding private investigation/electronic surveillance technology. I wish to extend my services to the Internet to share and exchange information on security and privacy protection issues. We are making a lot of very informative info available FREE on the Internet. This includes back issues of my newsletter "Inside Secrets", my schematics and plans, resources, guides, and other information. For details on accessing these FREE services, send an e-mail message to INFO@ENLOW.COM you can also FTP to ENLOW.COM or FTP.ENLOW.COM, and login as anonymous (put your email address as the password). There is a listserver in place to send you files if you do not have access to FTP. Your comments and suggestions are welcome. Thanks for your time. ------------------------------ Date: 15 April 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories; risks-15.75 gives WAIS info. "Mosaic http://www.csl.sri.com&" gets you CSL for info; check for recent issues in case you suspect a disruption. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.76 ************************