Subject: RISKS DIGEST 16.27 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 21 July 1994 Volume 16 : Issue 27 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) ***** Contents: Pentagon computers cracked (Mich Kabay) Chemical Bank ATM's go down after snafu (Josh Rivel) Re: Crashed Bank Teller (William Hugh Murray) EPIC on Gore Letter (David Sobel) Re: Victim on the infobahn (Marc Horowitz, Jeffrey I. Schiller, Max Hadley, Bob Rahe, John W. Burgeson, Mich Kabay, Andrew Marc Greene) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 21 Jul 94 19:45:03 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Pentagon computers cracked >From the Associated Press newswire (94.07.21 @ 12:15 EDST) via Executive News Service (GO ENS) on CompuServe: Internet-Hackers By JOHN DIAMOND, Associated Press Writer "WASHINGTON (AP) -- Intruders have been tapping into the Pentagon's unclassified computer system through the Internet for the past seven months and some have stolen, altered and erased records, officials said today. Investigators have found no indication that the hackers have entered classified systems that control critical functions such as nuclear weapons and the movement of troops and ships." The author provides the following key points: o "...Betsy McDonald, spokeswoman for the Defense Information Systems Agency, said the compromised systems include those used for ballistic weapons research, aircraft and ship design, military payroll, personnel records, procurement, electronic mail, supercomputer modeling of battlefield environments and computer security research." o The Pentagon is taking the attacks seriously: the intruders evidently breached data confidentiality, damaged information integrity and threatened system availability. o The US and foreign attackers were able "to guarantee their ability to gain later access and to keep tabs on passwords needed to get into the system." o Michael Higgins, Deputy Director for Information Security at DISA (Defense Information Systems Agency) is reported as having said that '"major portions" of the Defense Department's unclassified networks had been penetrated by hackers, "adversely affecting DOD military readiness." o The attacks are related to the February 1994 CERT alert about network sniffers trapping passwords. o Because of the nature of computer crime, the Pentagon admits that it is difficult or impossible to determine the extent of the security breaches. o The Senate Armed Services Committee has been echoing the warnings of analysts [such as Winn Schwartau] about systematic attacks on the information infrastructure: "With almost no security protections, the nation faces the prospect of potentially grievous assaults by even small groups with limited resources." o Pentagon sources pointed to "the inherent difficulty of security for a computer system that, by its very design, allows outside access and easy communication." [Comments from MK: gosh, and only one day after the preliminary announcement of the Second International Conference on Information Warfare, too... ] Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn ------------------------------ Date: Thu, 21 Jul 1994 03:06:21 -0400 (EDT) From: csfb1!phantom!jrivel@uunet.uu.net (Josh Rivel) Subject: Chemical Bank ATM's go down after snafu Chemical Bank's ATMs were out of commission for more than five hours, beginning at 6:45 a.m. on 20 July 1994. A routine file update was botched, overloading the computer system. This came six months after Chemical systematically [no pun intended] charged its customers twice for cash withdrawals. [PGN abstracting from a NY Post article by Paul Tharp, Wed 20 Jul 1994.] ------------------------------ Date: Thu, 21 Jul 94 18:56 EST From: William Hugh Murray <0003158580@mcimail.com> Subject: Re: Crashed bank teller (Goossens, RISKS-16.26) > The display I encountered contained a number of error messages (file > not found, could not create file, etc) followed by the prompt (A>). Users of operating systems, such as MS-DOS and Unix, in which the operating system is owned by or owns the "standard input" often believe that the normal way for an application to fail is to return control to the user. (I have had this discussion ad nauseam with our beloved moderator, who seems unable to believe in any other failure mode for more than a few minutes at a time.) In fact, for the first 30 years of computing that was an unusual way of failing. With the exception of those running on Unix, most applications failed by doing nothing or by returning the user to logon. IBM's MVS, the successor to an operating system for processing punched paper input and producing printed paper output, did not even know about terminals and had no operating system prompt. The prompt that the users saw came from a subsystem such as CICS. CICS Applications failed in many mysterious and disruptive ways but almost never by giving a legitimate user of an application unintended operating system privileges. Applications running on Unix, an operating system originally intended by programmers for programmers, usually fail by returning control to the user at the operating system prompt. To limit the exposures associated with this mode of failure, Unix was extended with the "setuid" (set user id) function. The intent was to have applications run with a special limited profile. This would permit a user to run an application with privileges that would not be appropriate with all of the generality of the operating system. In practice programmers use the function to have their programs run with either their privileges or with "root" privileges. Setuid has hurt instead of helped. Modern operating systems, such as OS/400, often have a mechanism like setuid that permits a user to run an application with privileges that are unique to the application. However, they do not permit the user to retain those privileges across the failure of the application. (Indeed, one of the things that characterizes such operating systems is that they have very few failure modes.) Application machines, such as ATMs or the Teller described by the poster, should normally fail by doing nothing. While it is appropriate for my program to fail by returning ME to the operating system, my program should not fail by returning YOU to the operating system prompt with privileges that are different from those that you have on your own. Application machines should fail by doing nothing. PAC-MAN never fails by exposing either itself or its host environment. William Hugh Murray, New Canaan, Connecticut ------------------------------ Date: Thu, 21 Jul 1994 14:55:05 EST From: David Sobel Subject: EPIC on Gore Letter [Reprinted with permission from EPIC ALERT, Volume 1.04 (special edition), July 21, 1994 Published by the Electronic Privacy Information Center (EPIC) Washington, DC (Alert@epic.org) SPECIAL EDITION -- "SON OF CLIPPER" [excerpts] [1] Administration "Reversal" on Clipper [2] EPIC Statement [3] Letter from Gore to Cantwell [4] What You Can Do (Email the VP) ======================================================================= [1] Administration "Reversal" on Clipper ======================================================================= A letter from Vice President Al Gore to Representative Maria Cantwell (D-WA) sent this week during Congressional debate on the Export Administration Act has raised important questions about the current state of the Clipper proposal. Some have hailed the statement as a major reversal. Others say the letter seals a bad deal. Below we have included the letter from the Vice President, a statement from EPIC, and recommendations for further action. ======================================================================= [2] EPIC Statement on Gore Letter to Cantwell ======================================================================= News reports that the Clinton Administration has reversed itself on encryption policy are not supported by the letter from Vice President Gore to Maria Cantwell regarding export control policy. In fact, the letter reiterates the White House's commitment to the NSA's key escrow proposal and calls on the private sector to develop products that will facilitate electronic surveillance. The letter from the Vice President calls on the government and the industry to develop jointly systems for key escrow cryptography. Key escrow is the central feature of the Clipper chip and the NSA's recommended method for electronic surveillance of digital communications. The letter also reaffirms the Administration's support for Clipper Chip as the federal standard for voice networks. There is no indication that the White House will withdraw this proposal. Statements that Clipper is "dead" are absurd. The letter offers no changes in export control policy. It recommends instead that the status quo be maintained and that more studies be conducted. (The White House already completed such a study earlier this year. The results were never disclosed to the public, despite EPIC's request for release of the findings under the Freedom of Information Act.) This is a significant setback for groups expecting that export control laws would be revised this year. The White House expresses a willingness to allow unclassified algorithms and to hold key escrow agents liable for misuse. These are the only provisions of the Gore letter favorable to the user community. But neither provision would even be necessary if the White House did not attempt to regulate cryptography in the first place. The Administration's willingness to accept private sector alternatives to Clipper for data networks essentially ratifies an agreement to develop "wiretap ready" technologies for data networks. We believe the letter from the Vice President is essentially a blueprint for electronic surveillance of digital networks. The government will set out the requirements for surveillance systems such as key escrow, and the industry will build complying systems. The plan dovetails neatly with the FBI's Digital Telephony proposal, which will establish legal penalties for companies and users that design systems that cannot be wiretapped. We do not believe this is in the interests of users of the information highway. Key escrow necessarily weakens the security and privacy of electronic communications. It makes networks vulnerable to tampering and confidential messages subject to compromise. It is the approach urged by organizations that specialize in electronic eavesdropping. No group of Internet users has ever called for key escrow encryption. If this proposal goes forward, electronic surveillance will almost certainly increase, network security will be weakened, and people who design strong cryptography without key escrow could become criminals. This is not a victory for freedom or privacy. We support unclassified standards and relaxation of export controls. We cannot support the premise that the government and industry should design key escrow systems. We also do not believe that Clipper is an appropriate standard for federal voice communications. We are asking the Vice President to reconsider his position and urging network users to make known their concerns about the proposal. Electronic Privacy Information Center Washington, DC July 21, 1994 ======================================================================= [3] Letter from Gore to Cantwell ======================================================================= THE VICE PRESIDENT WASHINGTON July 20, 1994 The Honorable Maria Cantwell House of Representatives Washington, DC 20515 "Dear Maria, "I write today to express my sincere appreciation of your efforts to move the national debate forward on the issue of information security and export controls. I share your strong conviction for the need to develop a comprehensive policy regarding encryption, incorporating an export policy that does not disadvantage American software companies in world markets while preserving our law enforcement and national security goals. "As you know, the Administration disagrees with you on the extent to which existing controls are harming U.S. industry in the short run and the extent to which their immediate relaxation would affect national security. For that reason we have supported a five-month Presidential study. In conducting this study, I want to assure you that the Administration will use the best available resources of the federal government. This will include the active participation of the National Economic Council and the Department of Commerce. In addition, consistent with the Senate-passed language, the first study will be completed within 150 days of passage of the Export Administration Act reauthorization bill, with the second study to be completed within one year after the completion of the first. I want to personally assure you that we will reassess our existing export controls based on the results of these studies. Moreover, all programs with encryption that can be exported today will continue to be exportable. "On the other hand, we agree that we need to take action this year to ensure that over time American companies are able to include information security features in their program in order to maintain their international competitiveness. We can achieve this by entering into a new phase of cooperation among government, industry representatives and privacy advocates with a goal of trying to develop a key escrow encryption system that will provide strong encryption, be acceptable to computer users worldwide, and address our national security needs as well. "Key escrow encryption offers a very effective way to accomplish our mutual goals. That is why the Administration adopted the key escrow encryption standard in the "Clipper Chip" to provide very secure encryption for telephone communications while preserving the ability for law enforcement and national security. But the Clipper Chip is an approved federal standard for telephone communication and not for computer networks and video networks. For that reason, we are working with industry to investigate other technologies for these applications. "The administration understands the concerns that industry has regarding the Clipper Chip. We welcome the opportunity to work with industry to design a more versatile, less expensive system Such a key escrow scheme would be implementable in software, firmware or hardware, or any combination thereof, would not rely on a classified algorithm, would be voluntary, and would be exportable. While there are many severe challenges to developing such a system, we are committed to a diligent effort with industry and academics to achieve such a system. We welcome your offer to assist us in furthering this effort. "We also want to assure users of key escrow encryption products that they will not be subject to unauthorized electronic surveillance. As we have done with the Clipper Chip, future key escrow schemes must contain safeguards to provide for key disclosure only under legal authorization and should have audit procedures to ensure the integrity of the system. Escrow holders should be strictly liable for releasing keys without legal authorization. "We also recognize that a new key escrow encryption system must permit the use of private-sector key escrow agents as one option. It is also possible that as key escrow encryption technology spreads, companies may establish layered escrowing services for their own products. Having a number of escrow agents would give individuals and businesses more choice and flexibility in meeting their needs for secure communications. "I assure you the President and I are acutely aware of the need to balance economic and privacy needs with law enforcement and national security. This is not an easy task, I think that our approach offers the best opportunity to strike an appropriate balance. I am looking forward to working with you and others who share our interest in developing a comprehensive national policy on encryption. I am convinced that our cooperative endeavors will open new creative solutions to this critical problems." Sincerely /s/ Al Gore ======================================================================= [4] What You Can Do (Email the VP) ======================================================================= The Clipper debate has reached a critical juncture. The White House and industry are about to seal a deal to make key escrow the standard for encrypted communications. If you believe that individuals should have the right to make full use of new technologies to protect privacy, now is the time for your voice to be heard (and your email to be sent). EMAIL the Vice President at vice.president@whitehouse.gov - Thank him for the Administration's willingness to reconsider its views on Clipper. - Express support for the decision to support unclassified algorithms and liability for key escrow agents. - But urge him not to require key escrow as a standard for encryption products. - Emphasize that key escrow is the soul of Clipper, the method for conducting electronic surveillance of digital communications. - Call for extensive testing and studies before any key escrow system is deployed. You should also: - Urge him to withdraw Clipper as a standard for voice communications. - Urge him to support relaxation of export controls. - Ask for the public release of the earlier White House study on cryptography. - Ask for the public release of White House documents reviewing the weaknesses of the key escrow proposal. The Vice President has clearly shown a willingness to listen to the concerns of the user community on this issue. Your letter could make a difference. [This message is included for your information. Whether you agree or disagree with David's recommendations, if you care to, write and tell the VP and cc: David Sobel . PGN] ------------------------------ Date: Wed, 20 Jul 94 22:15:20 EDT From: Marc Horowitz Subject: Re: Victim on the infobahn (Donahue, RISKS-16.26) >> I'm thinking now of writing a magazine article on our >> experience, and am posting for two reasons. First, I'd like to hear >> from people who, like me, have become "victims on the infobahn," and >> second, I'd like to get some broader perspective. If this is a problem with the information superhighway, it's been around since the horse-and-buggy days the information dirt road. This is not a new problem. I can recall similar incidents happening over a decade ago, and I'm only 23 years old. I suspect occurrences that this problem will increase for a short period of time, while networking gains popularity, but decrease soon after, as data telecommunications (ISDN, frame relay, ATM, etc) becomes more popular. It's really hard to wake somebody up in the middle of the night with a misdirected ATM packet! I've yet to have someone complain at an errant ICMP echo, myself. Marc ------------------------------ Date: Thu, 21 Jul 94 00:28:35 -0400 From: Jeffrey I. Schiller Subject: Victim on the infobahn (Donahue, RISKS-16.26) This sort of situation is not new. I remember a problem we had with a uucp dial-out line in 1983. Someone added a dial-out entry but transposed two digits in the destination telephone number. This meant that once an hour we were calling up some poor folks and annoying them all night long! Luckily this only happened over one night. In the morning I investigated why none of our uucp connections to that host completed, and noticed the typo. I did call up the people who we had been bothering (sort of hoping that the number would be invalid and no one had been bothered!) and emphatically apologized for our error. They were understanding. I guess it helped that I was *not* a lawyer and was able to empathize with their plight. In fact I felt good about the call afterwards... now I knew that these folks would know what had happened and would not fear that someone was after them! Jeff ------------------------------ Date: Thu, 21 Jul 1994 11:25:10 +0100 From: mrh@shl.co.uk (Max Hadley) Subject: Re: Victim on the infobahn (Telephone protocols) (Donahue, 16.26) Mr Donahue's predicament is symptomatic of a wider problem which will grow over the next few years - 'semantic overload' of the telephone system. PTT's and Telco's are still stuck in a mode where a telephone line is used to allow one human being to talk to another. In fact, more and more phone lines are connected to machines, many of which can initiate as well as receive calls, and vary in levels of human compatibility. Examples range from answering machines, through voice mail systems, fax machines, 'smart boxes', pagers, alarm systems, modems, all the way up members of the International Union of Deaf-Mute Dyslexic Telephonists :-). The current telephone system is a mess - it allows anything to connect to anything at any time, regardless of compatibility, and regardless of the consequences. Yet this proliferation of machines that use the telephone network has arisen precisely because of the flexibility of connection on the telephone network. People use the phone system to send text messages via fax and email, although the Telex system in theory provides most of the same facilities. It just wasn't flexible enough. To make the situation more bearable, without restricting connectivity, an extension of caller ID could be made, so the calling line can say 'I am a xxxx and I understand yyyy protocols'. Only once a 'speech' protocol is negotiated between the ends of the link does the phone actually ring. Of course, this requires Mr Donohue to purchase a phone with this facility. However, such a phone could also route calls around his fax, modem, answering machine &WHY, and would provide a better solution than the various 'smart boxes' currently on the market. Or we could sit back and wait for the Coming Of Broadband ISDN/ATM. Max Hadley | Stewart Hughes Ltd., Principal Consultant | School Lane, Chandlers Ford | Eastleigh, Hampshire SO53 4YG UK mrh@shl.co.uk | Tel: +44 (0) 703 270027 x215 mrh@shluk.uucp | Fax: +44 (0) 703 270007 ------------------------------ Date: Thu, 21 Jul 1994 08:28:37 EDT From: bob@hobbes.dtcc.edu (Bob Rahe) Subject: Re: Victim on the infobahn (Bill Donahue) In RISKS-16.26 Bill Donahue writes of an incident of a 'modem' dialing his home and giving him and his wife some apparent cause for worry for their safety. I'm not so sure I'd call his experience a fatality on the info-bahn, maybe a pebble on the windshield(!). I had a similar experience when a local school district put my home phone number into their FAX machine as the number for the local TV station. I'd get calls every 5 minutes for random amounts of time and random times of the day. By the time I'd run upstairs and get my fax software ready to go (faxes have a "chirp" from the calling to caller machines that make it easy to tell it was a fax) it would stop. Then it would quit for days or weeks... I finally caught them, read the organization from the top of the fax, and called. They were profusely sorry but... I wonder tho, most of the failure here was purely human - mis-setting the number and then failing to notice that the fax never got sent to its intended recipient. I'd assume the machine would somehow tell the operator that an automatic retry had failed after attempts. But then again, when I called it took a bit to explain what the problem was to them.... Bob Rahe, Delaware Tech&Comm College, Computer Center, Dover, Delaware Internet: bob@hobbes.dtcc.edu ------------------------------ Date: Thu, 21 Jul 94 12:01:57 CDT From: "John W. Burgeson, 73531,1501 on Compuserve" Subject: Victim on the Autobahn Bill Donahue's experience at least happened "all at once." We had the misfortune to get a new phone number which had once been that of a genealogy BBS -- it took us a few weeks to realize that this number was being shared by genealogy buffs all over the world! For several reasons, we could not change our number. The calls continued at the rate of 2 to 3 a week for over a year! I put appeals on a number of FORUMS in PRODIGY & Compuserve (DO NOT CALL 512-250-xxxx) and after 18 months the calls are down to about one or two a month. My TAD response, you might believe, is just a trifle surly! John W. Burgeson, 73531,1501 on Compuserve ------------------------------ Date: 21 Jul 94 08:33:55 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Harassment by modem (Donahue, RISKS-16.26) Thanks to Mr. Donahue for posting the interesting anecdote about the heavy-breathing modem. Periodically over the years, people have set their fax machine to dialing my voice line instead of my fax line. Some of the fax machines have been quite persistent; usually the fax operator will notice the repeated failures and call up to complain that my fax machine isn't responding. However, in one case, the maddening thing dialed me up every ten minutes for over two hours. I fixed _that_ one by hooking my fax machine to my voice line just before the next scheduled interruption and actually receiving the fax. It would make sense for fax and modem manufacturers to distinguish between a non-responding telephone line (no answer or busy) and a non-responding _device_. Most modems can generate an error message (e.g., "VOICE") when appropriately programmed; it would be helpful if both fax machines and modems treated an answer-but-no-tone event by alerting the operator immediately instead of mindlessly redialing. Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn P.S. Two minor matters. ------------------------------ Date: Thu, 21 Jul 1994 12:50 -0400 From: Andrew_Marc_Greene@frankston.com Subject: Modems and faxes I've said it before and I'll say it again. Modems and fax machines should be programmed that on an outgoing call, until they establish a connection, they play a digitized recording along the lines of "This is a modem call" -- and there should be an AT command to append "from xxx-xxx-xxxx" Of course, this isn't the kind of feature that will cause many potential customers to choose your line over someone else's. - Andrew Greene [Bob Frankston suggested once again that we should have some redundant check digits on phone numbers as well, to minimize wrong numbers. Our subsequent off-line discussion went into how knowledge of the algorithm would not prevent people from fabricating consistent but incorrect numbers. I just thought I'd mention it... PGN] ------------------------------ Date: 31 May 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 (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains 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, THEN please send requests to (which is 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 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "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; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. 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 16.27 ************************