Subject: RISKS DIGEST 15.29 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 23 November 1993 Volume 15 : Issue 29 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Logic Bomb planted in retribution for nonpayment (Mich Kabay) Brazilian computer snarls in corruption probe (Mich Kabay) Digitized Photos (Mich Kabay) Magnetic Fields & Leukaemia (Mich Kabay) Who owns the unused cycles? (Bear Giles) Not-voting-by-phone Boulder over (Bear Giles) Tablespoons, or another risk? (Steve VanDevender) Charge cards from mail order houses (Ted Wobber) United Parcel Service signatures (Jim Carroll) Re: Massachusetts state police confusion (Brian Hawthorne) Re: Ada Usage (Douglas W. Jones, Robert I. Eachus) Re: UK government to scrap safety laws (Keith Lockstone) The RISKS Forum is a moderated digest discussing risks; comp.risks is its USENET counterpart. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. PLEASE SEND REQUESTS FOR SUBSCRIPTIONS, archive problems, and other information to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS". Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 15, 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. There are also alternative repositories, such as bitftp@pucc.Princeton.EDU . If you are interested in receiving RISKS via fax, please send E-mail to risks-fax@vortex.com, phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for information regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; instead, as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . 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: 23 Nov 93 16:51:46 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: Logic Bomb planted in retribution for nonpayment Excerpted from the Associated Press Newswire via Executive News Service (GO ENS) on CompuServe: APn 11/23 0106 BRF--Computer Virus WESTBURY, N.Y. (AP) -- A computer company owner and his technician are accused of planting a virus in a dissatisfied customer's computer system, after the customer refused to pay for a program. Michael Lofaro, 29, owner of MJL Design of Manhattan, and his technician, John Puzzo, 22, were charged Monday with attempted computer tampering and coercion, said Lt. Lawrence Mulvey of the Nassau County police. The article explains that the maximum penalties are 4-7 years and up to $5,000 in fines. The client, William Haberman, owner of Forecast Inc., a furniture company in Westbury, complained about poor performance in a program sold by MJL Design and refused to pay the full invoice when the vendor allegedly ignored his complaints. According to the accusation, Lofaro and Puzzo planted a ``computer virus'' [which I think is simply a logic bomb, judging from the phrasing--MK] and threatened to detonate it. The accused were arrested when they came to defuse the logic bomb. [Surprising to see the old confusion between viruses and logic bombs persisting in a newswire report.--MK] [Not surprising at all.--PGN] Michel E. Kabay, Ph.D. Director of Education National Computer Security Assn ------------------------------ Date: 23 Nov 93 16:52:01 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: Brazilian computer snarls in corruption probe >Excerpted from the United Press International newswire via Executive News Service (GO ENS) on CompuServe: UPn 11/18 1948 Data-packed computer snarls in Brazilian corruption probe BRASILIA (UPI) -- A congressional committee investigating massive fraud in Brazil was held up Thursday when the computers froze in response to a command to cross-reference data on thousands of checks, bank accounts and budget amendments between 1990 and 1992. The article explains that the network ran out of processing resources, including memory, when trying to track down corruption in the government. [Wonder if we'd need a supercomputer to track corruption in certain other governments?--MK] Michel E. Kabay, Ph.D. Director of Education National Computer Security Assn ------------------------------ Date: 23 Nov 93 16:52:27 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: Digitized Photos >Excerpted from the Associated Press newswire via Executive News Service (GO ENS) on CompuServe: APn 11/21 1531 Digital Licenses, By MARTIN FINUCANE, Associated Press Writer BOSTON (AP) -- Fourteen states and two Canadian provinces are planning to use digitized photographs of drivers on licenses, adding people's faces to their already-vast computer files. Once a photo is scanned into a computer to be stored digitally, the image can easily be altered, matched with similar images or even transmitted around the world. Privacy experts worry that the information will be misused by people with bad intentions or by overzealous police. The article goes on to explain that privacy advocates are already worried about the potential for abuse. Possible abuses include o release of the pictures to the direct-marketing industry, which could target specific categories of people (e.g., bald people or those in need of dental care) for campaigns; o illegal use by criminals to stalk, harass or intimidate victims. The FBI is claimed to be interested in nationwide picture files and is currently upgrading its databases to handle pictures such as those from motor vehicle licenses. Even in police work, such files could be misused: ``For example, courts have frowned on police roundups of all young black men near a crime scene -- but police could use the computer to scan the pictures of every driver living in the area.'' Police could greatly increase the number of pictures shown to witnesses of crimes by including thousands of photos of innocent people--with a likely increase in the number of false positive misidentifications. Because the pictures will be stored in digital fashion, changing them will be very easy. Privacy watchdogs urge caution and thought as the systems are implemented. Michel E. Kabay, Ph.D. Director of Education National Computer Security Assn ------------------------------ Date: 23 Nov 93 16:52:47 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: Magnetic Fields & Leukaemia >Excerpted from the Reuter newswire via Executive News Service (GO ENS) on CompuServe: RTw 11/18 1718 MAGNETIC FIELDS DOUBLE RISK OF CHILD LEUKAEMIA-RESEARCH LONDON, Nov 19 (Reuter) - Children who live close to high voltage power lines and other electromagnetic fields may be doubling their risk of contracting leukaemia, according to research published on Friday. An analysis of three of the latest studies carried out in Denmark, Finland and Sweden also threw up evidence of an increased risk of nervous system tumours and other childhood cancers, although the link was less clear. The article goes on to explain that the analysis was published in a letter to The Lancet, a British medical journal. Unlike previous studies which were widely viewed as having insufficient sample sizes, ``Anders Ahlborn of Stockholm's Institute of Environmental Medicine and his Nordic colleagues looked at recent Danish and Finnish studies that used the entire population and a Swedish study restricted to people living close to power lines.'' [It will be interesting to see if the levels of electromagnetic disturbance from electronic equipment could affect us too.--MK] Michel E. Kabay, Ph.D. Director of Education National Computer Security Assn ------------------------------ Date: Wed, 17 Nov 1993 19:43:06 -0700 From: Bear Giles Subject: Who owns the unused cycles? Earlier today I talked my sys-admin into letting me install the software to help factor RSA-129 on my workstation. When I mentioned how easily it installed he suggested I run it on a number of other workstations -- after all I had login permissions for them all. An hour later a coworker was giving me a stern lecture about how I shouldn't run a process on his system in background without getting his full permission first (not only to run it and to be assured that it would not consume resources, but also that it satisfied *his* requirements for legitimacy). The fact that the process was nice'd and previously approved by the sys-admin was considered irrelevant. I've since talked to several other coworkers; about 1/3 feel the same as the coworker mentioned above, the other 2/3 feel that if the system resources are available they can be used by anyone as long as they don't impact the primary user. *Everyone* appears to believe that their view is obvious, although most admit that other views are not totally unreasonable. This specific application is trivial, but what does this portend for the future? It's not hard to identify legitimate background tasks which could be run by businesses overnight, but will efforts to use idle resources run into hostility by workers who feel that ``their'' workstation or PC is being grabbed by others who don't respect their privacy or ownership? Would such distributed software be acceptable at night, or by users without any indication of system load (be it ``perf meters'' or flashing disk lights), but not by users who could notice such indications of active processing? Distributed processing over LANs seems promising, but have users had individual PCs and workstations which acted alone too long for them to accept the idea of a supra-system computer? Bear Giles bear@cs.colorado.edu/fsl.noaa.gov ------------------------------ Date: Thu, 18 Nov 1993 21:27:06 -0700 From: Bear Giles Subject: Not-voting-by-phone Boulder over During the recent elections the people of Boulder, Colorado voted 11731 to 7926 *not* to implement a voting-by-phone system provided Constitutional questions were satisfied. (The Colorado Constitution requires that ballots not be individually identifiable; the proposal to print telephone ballots and "voter IDs" may violate this requirement. BTW, if this information is published it can be cross-referenced with public records (of registered voters and voting patterns) in a statistical attack on the anonymity of voters. But *not* publishing this information removes one of the strongest arguments for voting-by-phone). The ratio was quite consistent as the election results were announced, so it appeared that there was widespread distrust of this system despite substantial favorable press in the campus newspaper. Unfortunately, I don't know how much coverage the Boulder (city) paper provided; the Denver daily I read had no coverage of this issue. Of particular interest to RISKS readers is the fact that many proponents of this measure implicitly acknowledged that a person voting out of sight of election officials could be coerced, but they felt this was "irrelevant" since people who feared being coerced could simply vote at the regular polling place! The fact that anyone who could be coerced to vote a particular way could as easily be coerced to vote by phone, instead of in person, was not recognized. Bear Giles bear@fsl.noaa.gov ------------------------------ Date: Thu, 18 Nov 93 01:44:11 PST From: stevev@miser.uoregon.edu (Steve VanDevender) Subject: Tablespoons, or another risk? The poem "Tablespoons" allegedly created by writing Lewis Carroll's "Jabberwocky" into an Apple Newton seems to have words a little too far off the originals, even given the Newton's shaky handwriting analysis, and some of the words seem too well chosen. It really looks to me as if someone wrote a parody of "Jabberwocky" with veiled references to things from the world of computers and the Internet and passed it off with a clever framing story. It can be too easy to believe what you read on the net, especially if an author plays off of expectations well. ------------------------------ Date: Thu, 18 Nov 93 17:06:13 -0800 From: wobber@src.dec.com Subject: Charge cards from mail order houses My wife obtained a credit card from a local branch office of a clothing retailer (Talbots) who also happens to be in the mail order business. Recently I had an opportunity to place an order using one of their catalogs that was mailed to our home. The phone sales agent was able to look up my wife's account from a 5-digit number printed on the catalog. Now, my wife and I don't share last names. Nonetheless, the sales agent was willing to accept an order in my name, send it to a location of my choosing, and charge it to my wife's account!! Seems like anyone who picked up the catalog from the trash could have made such an order. I'll be more wary of accepting new credit cards in the future. Ted Wobber -- wobber@src.dec.com DEC Systems Research Center [Worse yet, just pick five digits at random! But maybe the fact that the addresses matched made it OK. PGN] ------------------------------ Date: Fri, 19 Nov 1993 11:00:44 -0500 From: jcarroll@jacc.com (Jim Carroll) Subject: United Parcel Service signatures UPS (United Parcel Service) arrived at my doorstep the other day, with yet another package for delivery. I signed the little handheld machine that they carry around, to signify my receipt of the package. I've been doing this for the last couple of years. UPS is the only courier (in Canada, in any event) to use these handy little devices. However, I began to wonder this time about UPS and signatures. UPS must have collected my signature in digital form over 50 times now through the past few years. Maybe my signature exists in some UPS database at this point? Maybe a smart hacker somewhere in the bowels of has figured out a way to download my signature from their field device? Maybe my digital signature can be misused in some fashion? What are the risks that are posed by UPS collecting digital signatures? Might those risks be compounded as more companies implemented field devices such as UPS? What should we as consumers being doing to protect ourselves? Should I even bother signing with my real signature, or should I just print out my name? Perhaps there is an interesting issue here that RISKS should explore. Jim Carroll, J.A. Carroll Consulting, Mississauga, Ontario jcarroll@jacc.com +1.905.855.2950 Co-Author, "The Canadian Internet Handbook", due March 1994 ------------------------------ Date: Mon, 22 Nov 1993 10:37:19 +0500 From: brian@suneast.east.sun.com (Brian Hawthorne,SunSelect Strategic Marketing) Subject: Re: Massachusetts state police confusion (Garfinkel, RISKS-15.26) In RISKS-15.26, Simson L. Garfinkel forwarded a claim by a David Lewis of the Registry of Motor vehicles that the confusion was caused by: "They got stickers confused with people who were supposed to get food stamps. So the people [who were supposed to get] the food stamp books got the gun permits, and the people who were supposed to get gun permits got food stamps." I would urge Mr. Garfinkel to seek independent confirmation in the future. Were Mr. Lewis' claim to be true, it would imply that my wife was a recipient of food stamps. While she did provide graphic design services to the Department of Public Welfare for several years, she has never been a client of theirs. Both Mr. Lewis and Eric Forak (in Risks 15.28) make the assertion that gun permits were actually ISSUED to food stamp recipients. As far as I know, the only mixup resulted a renewal application being sent to the wrong list of people. This has all the signs of degenerating into a rather nasty urban legend: "And then, the state police accidentally shipped fully automatic weapons to everyone who had ordered an MBTA pass by mail..." Let's stop this before it escalates further. If anyone else has any verifiable information (i.e. confirmable in writing from multiple sources), let's hear it. The current RISK? The ease of electronic communication makes small-town gossip circles look like peer-reviewed journals. Brian Hawthorne ------------------------------ Date: Thu, 18 Nov 1993 15:56:48 GMT From: jones%pyrite@uunet.uu.net (Douglas W. Jones,201H MLH,3193350740) Subject: Re: Ada Usage Harry Erwin (erwin@trwacs.fp.trw.com) wrote, on 15 Nov 1993, that > There are real problems for which Ada is not the best language. > > 1. Simulation--due to the lack of support for coroutines, Simula-style > semaphores, condition queues, call by name, and event lists, I have used Ada for a fairly large scale discrete event simulation project, and while I would have enjoyed having coroutines, the other issues were not problems. Specifically, having done a fair amount of research on event lists, I simply transliterated the best I had from older Pascal code, packaged it up to hide the details behind the cloak provided by Ada's package and private type mechanisms, and used it. My event set package is in a few repositories of public domain Ada code, and I'll gladly E-mail it to anyone who wants it. Call by name is not needed, but some form of procedure parameter would be nice. I found, though, that the lack of both never really got in the way. The generic and package mechanisms of Ada are powerful enough that I never encountered a case where they were insufficient, but they weren't always my first choice. Coroutines would also have been nice, but their lack never stood in the way of my project. In fact, I believe that Ada's tasking features could be quite effectively used to do process oriented simulation, but I haven't investigated this (my model wasn't expressed in process oriented terms). I was surprised to find that Ada's separation of package bodies from package definitions covers at least 90 percent of the uses I would have had for inheritance in an object oriented language. The remaining 10 percent, however, caused more than a few headaches. The biggest thing I miss in Ada is garbage collection, but this isn't a problem with Ada, as specified, but merely a problem with all the available implementations. Why isn't garbage collection more widely available?! Doug Jones jones@cs.uiowa.edu ------------------------------ Date: Thu, 18 Nov 1993 18:24:32 -0500 From: "Robert I. Eachus" Subject: Re: Ada Usage At a RISK of beating this horse to death, I'll respond to Harry Ervin (erwin@trwacs.fp.trw.com) who said: > There are real problems for which Ada is not the best language. Of course there are. Next. > 1. Simulation--due to the lack of support for coroutines, Simula-style > semaphores, condition queues, call by name, and event lists, Have you looked at the Ada 9X standard out for ballot? Make your desires known. (Most of this list is in there, but I guarantee you won't get classical Algol 60 call by name, no matter how many comments you send in. ;-) > 2. Test generation--for similar reasons, > 3. Multi-threaded applications with external inputs, where the usual > tasking libraries run into problems. What happens is that the OS > and the run-time environment sometimes need to enter messages or events > into the same queues. Unless the library has been carefully integrated > with the operating system, race conditions can occur, losing entries. This definitely sounds like a complaint about a bug in a particular implementation, and probably relates this to comp.risks. Do not believe that just because a compiler (or operating system) has been validated there are no bugs. On the other hand, please try not to confuse OS behavior with the properties of a programming language. > 4. Object-oriented programming in the full sense, Again get the Ada 9X draft and respond. Tucker Taft and a lot of others worked hard to get OOP all "in there." If there is anything missing please provide details. > 5. Completion routines for inter-device protocols, and For the Ada 9X Requirements Workshop several years ago in Florida, we had tee-shirts made up: "I don't know what the problem is... but Finalization is the answer." It's in there, as is support for heterogeneous distributed programming. > 6. Anything that needs to run close to the bare metal. It's in there. If there is something you think is missing from the Reference Manual or the Real-Time and Systems Programming annexes, please let ANSI or ISO know. (Is this starting to sound repetitious? Okay, I'll stop now.) Robert I. Eachus ------------------------------ Date: Thu, 18 Nov 93 11:37 GMT0 From: Keith Lockstone Subject: Re: UK government to scrap safety laws This posting underlines a fundamental polarity between safety and `free enterprise' - best summed up by: [The Herald of] Free Enterprise puts to sea again - with its bow doors open. Keith Lockstone ------------------------------ End of RISKS-FORUM Digest 15.29 ************************