precedence: bulk Subject: RISKS DIGEST 19.35 RISKS-LIST: Risks-Forum Digest Friday 29 August 1997 Volume 19 : Issue 35 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** Contents: Prosecution for pager interceptions (Steven Bellovin) Spy phones trace cheating husbands -- and employees (Mathew) Book burning on the Web: AOL and columnist sued (Mark Rebuck) Federal Web Sites Lack Privacy Safeguards (Edupage) Hacking Risks, Paying for tracking you down (Robert J. Perillo) Tcl 8.0 Y2K Risk (Lloyd Wood) Photocopier codes (Marcus L. Rowland) Oracle web server on Unix and passwords (Dawn Myfanwy Cohen) Relying on systems maintenance taking place in another time zone (Olivier MJ Crepin-Leblond) Re: Spelling-checker risks (Dave Katz) Mangled characters in text ("ET") Re: SET Risks (Tony Lewis, Martin Poole) Intentional analysis, re: SET Risks (Charlie Lane) Re: USC 47:227 (Duane Thompson) Re: Public loo guilty of making nuisance calls (Aaron M. Renn) Re: Tobacco Deal Could Set Precedent for Would-be Net Censors (David T.S. Fraser) Risks of believing the obvious, though impossible (Sam Lepore, PGN, Sam) ICDCS-18 call for papers (Diego Latella) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 27 Aug 1997 22:07:22 -0400 From: Steven Bellovin Subject: Prosecution for pager interceptions A New Jersey company has been charged with illegally intercepting and selling messages sent via a paging service. The messages -- the content of which was sold to news organizations -- were intended for delivery to the offices of various senior New York City officials, including the mayor's office and various top police and fire department officers. That alone wouldn't make this a story for RISKS. What makes it interesting is why these messages were sent via pager -- the police department considered them to be too sensitive to broadcast on police radio frequencies. After all, anyone with a scanner could hear those messages, but pager messages are blessed with special pixie dust known as "digital format". Besides -- intercepting those messages is illegal, unlike using a scanner. The obvious answer is to use cryptography, of course. But does anyone make a PGP-capable pager? [Added note from Steve:] The NYT story also quotes PGN as saying this is the first such case [PGN was referring to the first prosecution] he knew of. Actually, the hacker community has been doing this for years -- there was a demo at H.O.P.E. (Hackers on Planet Earth, Aug 13-14, 1994, New York) -- with a screen displaying all incoming pages in real-time. [No surprise there. That "community" is generally way ahead of the would-be "protectors" and users of the computer-communication infrastructure. Incidentally, the name of the company is Breaking News Network, a wonderful pun in itself, although Breakin' News Network would have been even cuter. PGN] [Moderator's comment on Steve's advice to use encryption: With the new legislation to pay medical schools *not* to teach students, perhaps we will enter an era when the U.S. Government pays cryptographers *not* to do research. (I know April Fools' Day is still 7 months away, but I could not resist.) PGN] [A further note from Steve included an article by Amy Westfeldt in *The New York Times* of 29 Aug 1997 to the effect that BNN denies intercepting the messages, and blames two disgruntled former volunteers who were released six months ago. BNN claims it did not even have the facilities to do the cloning/scanning. BNN's attorney accused prosecutors and NYC officials of targeting BNN because this incident had embarrassed Mayor Giuliani. A spokesman for the mayor countered, noting that this was a federal prosecution, not a city action. PGN Abstracting] ------------------------------ Date: Wed, 27 Aug 1997 10:40:50 -0400 From: mathew Subject: Spy phones trace cheating husbands -- and employees Electronic Telegraph, , 27th August 1997: Spy phones trace cheating husbands (By Robert Uhlig, Technology Correspondent) A MOBILE telephone being developed by British Telecom could soon spell an end to the deceptions by idle employees, stressed executives and adulterers. The Mobile Social Alarm or Mosa, currently under development at BT, will be the first telephone that can send precise details of the caller's location to the person receiving the call. Workers will no longer be able to phone the office pretending to be sick when they are at the beach and movements of cheating spouses will be exposed because the phone will show the caller's location to within 30 feet. According to Don Golding, a mobile applications engineer in charge of the project, companies will also be able to call the Mosa-phone without their employees' knowledge to track staff. What gets me about this story is the gleeful reporting of the fact that companies will be able to call your phone and trace your exact location, without your knowledge or consent -- and that this is apparently a deliberately designed-in feature of the system. Does Don Golding read RISKS, I wonder? mathew [The Southern California ladies will use a Her-Mosa Beach Model. PGN] ------------------------------ Date: Thu, 28 Aug 1997 12:49:27 -0400 From: Mark Rebuck Subject: Book burning on the Web: AOL and columnist sued Sidney Blumenthal, a former advisor to President Clinton, has filed a $30 million defamation lawsuit against cyber-columnist Matt Drudge and AOL. Normally, I don't get too excited about defamation/slander suits. However, the following quote from William McDaniel, attorney for Mr. Drudge, managed to get my attention: > [McDaniel said,] "one special aspect of defamation over the Internet is > that it is difficult to remove the false material" because it can be > downloaded, printed or stored by any number of readers. Perhaps I am just being paranoid, but McDaniel's statement sounds similar to "Darn it, we can't burn books on the Web like we can in the real world!" (I read about the lawsuit from an AP item in USA Today: www.usatoday.com.) -Mark Rebuck, rebuck@us.ibm.com ------------------------------ Date: Thu, 28 Aug 1997 11:30:29 -0400 From: Edupage Editors Subject: Federal Web Sites Lack Privacy Safeguards (Edupage) OMB Watch, a nonprofit group that monitors government activities, faults the federal government for its lackadaisical approach to protecting the privacy of government agency Web site visitors. "There is no government-wide policy regarding privacy concerns on federal Web sites... Agencies collect personal information about visitors to their Web sites, but fail to tell them why that information is being collected and what it is being used for," says an OMB Watch information specialist. Nearly half of 70 federal agencies collect information about their online visitors, but only 11 inform them how that information will be used. Three agencies, including the National Science Foundation, were collecting cookies -- a set of data that enables the Web server to track a user's patterns and preferences -- but all three have stopped following the release of OMB Watch's draft report. (TechWire 27 Aug 1997; Edupage, 28 August 1997) ------------------------------ Date: Tue, 26 Aug 97 12:45 EDT From: Perillo@DOCKMASTER.NCSC.MIL Subject: Hacking Risks, Paying for tracking you down Wendell Dingus, a U.S. hacker, was sentenced by a Tennessee federal court in late May to six months of home monitoring for violations of the amended 1986 Computer Fraud and Abuse Act. Wendell Dingus admitted to a series of attacks to gain unauthorized entry into U.S. Air Force and NASA computers using a Vanderbilt University computer to obtain log-in passwords. What is interesting about this case is that the damages to meet the $5,000 requirement of the Law were not based on the harm of the hacking, but based on the cost of tracking and catching the hacker. The court ordered him to pay $40,000 restitution to the Air Force Information Warfare Center (AFIWC, San Antonio Tx) for their time and effort involved in tracking him. According to Airmen at AFIWC, their not paid that much. It also seems strange that we are prosecuting people for computer crimes not based on the damage that they may have caused, but based on the amount of time and money it takes to track them down or fix the systems to prevent future unauthorized entry? When the police arrest a robber or burglar, they are charged based on how much they stole, not on how much money, time, and effort it took the police to catch them. This may be caused by our failure to develop adequate risk models for determining the true cost of an unauthorized computer access, or the correct valuation of electronic content? [Reference Secure Computing, Info Security News, July 1997, "Hacker Ordered to Pay $40,000 Restitution", page 19] Robert J. Perillo, CCP Richmond, VA Perillo@dockmaster.ncsc.mil ------------------------------ Date: Tue, 26 Aug 1997 21:09:43 +0100 (BST) From: Lloyd Wood Subject: Tcl 8.0 Y2K Risk Sun's scripting division has released Tcl 8.0, a fashionable bytecode compiler reworking of the Tcl interpreter to help Tcl scale better. Making it compilable required some changes in semantics, but there were some other changes as well. In particular, http://sunscript.sun.com/TclTkCore/8.0.html Notes: There are also a few other minor incompatibilities in Tcl 8.0 and Tk 8.0: [..] 2.2-digit years are now parsed differently by the clock command to handle year 2000 issues better (years 00-38 are treated as 2000-2038 instead of 1900-1938). Supporting two-digit years in the first place was risky enough, but this change is bound to catch a lot of people out. It looks like the millennium problem may have come early for cutting-edge Tcl scripters with legacy code. PGP+44-1483-300800x3641 ------------------------------ Date: Wed, 27 Aug 1997 07:50:25 +0100 From: "Marcus L. Rowland" Subject: Photocopier codes I work in a school where the photocopier has a 5-digit key code; each department has its own code, so that usage can be taken from the correct budget. We probably have about 30 codes in use. In the course of time I've had to do work for some other departments, and have been rather surprised to learn that all of their codes begin with the same two digits, and that in the _majority_ of cases it is possible to enter another department's code by transposing two digits, omitting a digit, pressing the same digit twice instead of once, etc. I also accidentally discovered that "99999" was a valid but unused account, probably originally used for factory testing and never closed. Since it wasn't supposed to exist it wasn't checked during the billing process. All of the department codes were apparently entered by a representative of the copier company when the machine was supplied, and have never been changed. The reason I've been given for leaving the codes unchanged is that nobody would remember the new codes! The risks here should be obvious; my department's copying costs last year exceeded UKP 2000, and will be much higher this year because paper prices have risen. The temptation to "accidentally" enter the wrong code is sometimes very strong. In a business environment this form of cheating might lead to another department's projects going over budget, with effects on promotion etc. The manufacturers of these machines, and other coded devices, should surely know that similar codes and unused accounts are likely to cause problems, and instruct their installation personnel accordingly. And, of course, sites should check these matters and change the codes occasionally, not just leave everything to the manufacturers. Marcus L. Rowland http://www.ffutures.demon.co.uk/ ------------------------------ Date: Thu, 28 Aug 1997 10:34:33 -0400 (EDT) From: Dawn Myfanwy Cohen Subject: Oracle web server on Unix and passwords Maybe I'm missing something because I'm kind of new to both Oracle and web servers, but something strikes me as very wrong here. When you install the Oracle web server on Unix, the installation guide goes out of its way to tell you to set the umask to 022. It then, somewhere along the way sets up some configuration files which store some Oracle user names and passwords in plain vanilla ASCII text. These users correspond to ones that own applications that should be run off the web server. In addition, the admin name and password for the web server itself are stored in ASCII in these configuration files. Depending on what exactly you are doing with the server, your DBA name and password might also appear. Seems kind of silly to me to go through all the contortions a DBMS goes through to protect data only to have any old Unix user be able to get access by just looking up some password. You could argue that you should keep your database and Unix users on different machines. But first of all we don't have that luxury right now. Second, to my knowledge there was no warning to that effect. I don't have time right now to experiment with seeing what breaks if I change the protection of these files. I guess the risks here are bad combinations of defaults ... default to store passwords as ASCII ... default to store files as readable, etc. --Dawn Cohen ------------------------------ Date: Fri, 29 Aug 1997 13:43:39 +0100 From: Olivier MJ Crepin-Leblond Subject: Relying on systems maintenance taking place in another time zone The latest Network Solutions goof bumping NASDAQ off the net (Rodger, RISKS-19.34) reminded me of Daniel Pouzzner's original post (RISKS-19.25) describing the events when corrupted .COM and .NET DNS tables were released at 2:30am EDT. Obviously the idea behind releasing the files at 2:30am EDT is to minimise the impact of updates on the geographically local network population. Computer maintenance tasks are traditionally done at night for that reason. The trouble with maintaining zone DNS files for the Internet is that it's always 12 noon somewhere on the Net. So FOOBARS such as the one described in RISKS-19.25 affected .COM and .NET users in Europe (morning work) and Asia (daytime work) way more than in the US where most users were asleep at that time). It can therefore be argued that the fact that it took 4 hours before corrected files were released, meant that European users lost 4 hours of valuable daytime working time, while the error came-through virtually unnoticed in the US. (apart from all of the e-mail bounces) That's the RISK of relying on a system whose mission-critical maintenance work takes place in another time zone. Olivier MJ Crepin-Leblond, Ph.D. GIH Ltd, London, UK http://www.gih.com ------------------------------ Date: 26 Aug 1997 23:33:17 -0700 From: Dave Katz Subject: Re: Spelling-checker risks (Bird, RISKS-19.34) The piece about "Semper Fi" being corrected to "Semi-pro fiddles" reminded me of my favorite spell check faux pas. One of the then-unique characteristics of MTS (the Michigan Terminal System, a now-extinct o/s for IBM mainframes in the proud academic tradition) was that it provided a spelling corrector using a Soundex variant--if you accidentally typed "sigon", it would respond with, "Do you mean 'Signon'?" After James Duderstadt was named President of the University of Michigan, it was discovered that if you typed "Duderstadt", the system would respond, "Do you mean 'dunderhead'?" I believe it got a new dictionary entry shortly thereafter. Although there was no fallout in this particular case, it does underscore the political risks of unchaperoned spell checkers. [Incidentally, several readers responded that it must have been the spelled-out "Semper fideles" that was corrected to "Semi-pro fiddles". I had assumed that was obvious from context, but apparently should have made it more explicit by editing the contribution and spelling it out! PGN] ------------------------------ Date: Wed, 27 Aug 1997 09:41:33 -0400 From: "ET" Subject: Mangled characters in text In RISKS-19.33 and 19.34, I noticed the following text: B&t.itN [Barnes and Noble] B&ytetN AT&sglyT [AT and T] My guess is some interaction with some software in which ampersand is a reserved character (like in HTML). From context, it was easy to see that 4 apparently random characters were inserted after the ampersands in question. I am curious to see what the second- and third-order mangling might produce. [Lots of systems and subsystems preempt commonly used characters. PGN] ------------------------------ Date: Mon, 25 Aug 1997 12:28:59 -0700 From: "Lewis, Tony" Subject: Re: SET Risks (Svigals, RISKS-19.31) > The SET process claims to be better than using a credit card on the > Internet. However, the SET process has three serious exposures - confirmed > with IBM and HP/Verifone. The process does NOT know who is presenting the > certificate. The security of SET is based on the authentication that occurs before a certificate is issued. Once the cardholder has obtained the certificate, the cardholder wallet will hold the certificate and the user's password to the wallet prevents unauthorized access. > The process does NOT know if merchant employees have > redirected the certificate through another merchant. SET payment instructions identify the merchant for whom they were created. They cannot be redirected to another merchant. > All of the critical software is directly accessible by the card users, > merchant employees and bank employees. Historically, these individuals > have been the prime source of fraud in credit-card transaction systems. SET is designed to prevent unauthorized parties from using payment cards on the Internet. It protects the transaction data as it flows between computers. There is no way that a transaction protocol can protect the data from illicit use once it has arrived at its intended destination. > There are more than 50 other card security products available for Internet > usage. They are generally simplier, faster, and avoid the SET exposures > identified above. Internet transaction users might try the viable > alternatives. jerome svigals, smartcard@sprynet.com While I do not claim to have reviewed every possible means of payment on the Internet, it is difficult to give any credibility to this claim. 1. In order to know who is presenting a payment card, the system would need a foolproof identity system. Since no such system exists on a worldwide basis, it is impossible for any of these 50 systems to overcome the first exposure. 2. In order to prevent merchant employees from redirecting transactions to another merchant, the system would have to involve three parties in the transaction: the cardholder, the merchant and a system to ensure that both parties are doing business with whom they intend. Any of these 50 systems that only involve the cardholder and merchant cannot overcome the second exposure. 3. Any general-purpose card security product will have some aspect of the software available on the user's computer. Therefore, there is no way to protect against access by the card user. Further, unless the card processor has changed their authorization and clearing systems, any Internet payment system will continue to go through legacy systems at the acquirer and issuer so there is no protection against access by the "bank" employees. I do expect it is likely that most card security products will protect against unauthorized access to data by merchant employees, however, that will be true whether the card security product implements SET or some other protection mechanism. In summary, SET does not attempt to address all of the issues raised by jerome svigals, but his claim that every other product avoids the exposures he described is questionable. Tony Lewis (tlewis@visa.com), Chief Systems Architect, Internet Commerce Visa International Service Association ------------------------------ Date: Wed, 27 Aug 1997 10:33:06 +0100 (BST) From: mpoole@uhea904.gb.ec.ps.net Subject: Re: SET Risks (svigals, 19.34 & Sterling, 19.33) The concept that Mondex is some sort of panacea for Internet commerce is one of the more blatant pieces of hype I have yet seen in RISKS, and for one of the simplest reasons: the number of PCs with smart-card readers. Yet, SET appears to equally unsuited to the job, for the very reasons cited. I keep getting the feeling that the only real money that will be made on the Internet will that that reaped by the snake-oil merchants selling the latest and greatest commerce system. Martin Poole mpoole@quatermass.gb.ec.ps.net ------------------------------ Date: Thu, 28 Aug 97 08:58:40 -0700 From: Charlie Lane Subject: Intentional analysis, re: SET risks (Svigals, RISKS-19.34 et al) OK, lots of us are following the technical discussion about secure payment with interest, but one aspect seems to be missing: the link to the (human) intentions. Here's the basic intention of a transaction: I want to make you a bit richer (money in your account to spend) in return for you making me happier (giving me something I want). Now, notice that I'm not essentially concerned about who you are: the point is that I do want to be assured that the person or organisation I am making richer is the one that will provide me with a product. It is the link between product and payment that is the crux. What I look for in a transaction is an assured offer of product for payment (i.e., a validated advertisement) containing an assured route for payment and an assurance that product will follow. Unless those concerned with electronic payment tackle the whole intention transaction from offer to receipt of product, the risks to the public will remain. (By the way, intentional analysis is also a big research topic in another technical area: that of pre-analysing telecoms network services to discover in advance any unwanted interactions, before large numbers of the public start phoning help desks to complain. If you can solve the intentional analysis of transactions, you might be on the way to solving the wider telecoms problem). Charlie Lane ------------------------------ Date: Thu, 28 Aug 1997 09:13:29 -0700 (PDT) From: Duane Thompson Subject: Re: USC 47:227 (Kabay, RISKS-19.34) [...] My uninformed 2-cent comment: My reading of USC 47:227 seems to support the argument that any unsolicited e-mail is a violation of the section. It defines "telephone facsimile machine" as "equipment which has the capacity ...(B) to transcribe text or images (or both) from an electronic signal received over a regular telephone line onto paper." My computer has that capacity. Duane Thompson, Materials Management Solutions, Englewood, Colorado, USA http://ourworld.compuserve.com/homepages/dst ------------------------------ Date: Tue, 26 Aug 1997 16:15:20 -0500 From: "Aaron M. Renn" Subject: Re: Public loo guilty of making nuisance calls An interesting related incident. We have a modem bank that sends faxes (not junk, rest assured) out overnight in batch mode. Well, during installation, someone managed to wire two modems to the same circuit (or to cross some wires or some such similar tragedy). Since these modems needed do dial out via a PBX, they had to dial "9" first. For long distance, the next number was a "1". When two fax jobs kicked off at the same time, occasionally the number sequence would end up as 9911, which dials 9 for an outside line, then 911! The police got called to this location every night and were not amused. This problem was not identified for quite some time because it was assumed to be a software bug. Just goes to show that our wire infrastructure is not nearly as error free as we would like to think. [... A new twist on accidental 911 autodialing! PGN] ------------------------------ Date: Wed, 27 Aug 1997 15:04:22 -0300 From: "David T.S. Fraser" Subject: Re: Tobacco Deal Could Set Precedent for Would-be Net Censors It is important to remember that the deal reached among the various parties in the tobacco settlement is, ultimately, a deal. As part of the give and take of negotiation, the tobacco companies voluntarily agreed to this restriction on their ability to advertise on the net. While it does have precedential value for contracts and other settlements, it was not arbitrarily imposed upon the tobacco companies by the government. A settlement is merely a contract--voluntarily entered into--not to enforce a claim in court. It is quite different, precedentially and constitutionally, from a law prohibiting internet advertising of a particular product from a foreign jurisdiction which is reachable from the jurisdiction in question. David T.S. Fraser Caledonia, NS, Canada fraserd@fox.nstn.ca ------------------------------ Date: Wed, 27 Aug 1997 23:48:51 -0700 From: Sam Lepore Subject: Risks of believing the obvious, though impossible There is a risk in believing the obvious because it sounds scientific, although it is impossible. This in turn can lead to a risk of believing the impossible will provide you with a safety factor. I read an article today about a solar study satellite launched into a gravi-stationary orbit around the Earth at the point where Earth gravitation and Sun gravitation are equalized - about 1 million miles out. The satellite is to study solar winds, flares, and particle streams. The article proclaimed the satellite would "give us a one hour warning of solar storms that would otherwise not be available so sensitive ground systems could be protected". It is obvious that the satellite will sense a storm before it reaches Earth. But unless there is a "new physics" like there is new math, the speed of light at which solar radiation travels is relatively close to the speed of light at which radio emanations from the satellite travel. So if the satellite senses a solar burst and radios its finding, how is that signal going to get here an hour before the storm? Oh, and at the commonly referenced speed of light, 1 million miles is only about 6 seconds out. Sam Lepore, San Francisco ------------------------------ Date: Thu, 28 Aug 97 14:14:34 PDT From: RISKS List Owner Subject: Risks of believing the obvious, though impossible Perhaps the physics are such that something in that remote environment can more sensitively detect the early manifestations of the solar activity long before we can from earth? ------------------------------ Date: Thu, 28 Aug 1997 22:41:57 -0700 From: Sam Lepore Subject: Risks of believing the obvious, though impossible Well, that would be the "obvious" part of my title. Newspapers have a way of reporting stories without detail so that only enough is explained to make one think you understand. I don't. Sam Lepore, San Francisco ------------------------------ Date: Wed, 27 Aug 1997 15:09:00 +0200 (MET DST) From: Diego Latella Subject: ICDCS-18 call for papers CALL FOR PAPERS [excerpted for RISKS] The 18th International Conference on Distributed Computing Systems Center of Mathematics and Computer Science (CWI) Amsterdam, The Netherlands 26-29 May 1998 The purpose of this conference is to bring together developers and researchers from universities, industry and government to advance the science and technology in distributed computing. The technical areas of the conference include [many relevant to RISKS, including Mobile Systems, Internet Applications, Interoperable Systems, Communication Protocols, Fault Tolerance, Availability and Security, to name just a few. PGN] See http://infolabwww.kub.nl:2080/infolab/ . Papers by 1 Oct 1997 to Michael Papazoglou (M.P.Papazoglou@kub.nl), Tilburg Univ., INFOLAB, PO Box 90153, 5000 LE Tilburg, The Netherlands, Phone: +31-13-466-23-49/30-20 Fax: +31-13-466-30-69, ------------------------------ Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 19.35 ************************