Subject: RISKS DIGEST 16.65 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 15 December 1994 Volume 16 : Issue 65 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** NOTE, THE SRI RISKS ARCHIVE SOURCE has moved to unix.sri.com. ***** ***** See FIRST item for further information, disclaimers, etc. ***** Contents: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. No, I'm not Newt. ("GingrichN" alias Steve Barr) Oral Hackers (Mark Colan via John Markoff) Technology Under the Weather (Gordon Symonds) Wendy's Stock (Charles R Trew) Re: Formal Methods and Exhaustive testing (Tony Lauck) Re: Mailing-list deadman switch (John Gardiner Myers) Re: Self-extracting emacs elisp code (Morgan Jones) RISKS demonstrates more RISKS in mailing list software (Sidney Markowitz) ---------------------------------------------------------------------- Date: 15 December 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 yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. CURRENT ARCHIVES: "ftp unix.sri.comlogin anonymousYourName cd risks or cwd risks, depending on your particular FTP. 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; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See 15/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 or http://all.net:8080 (the latter courtesy of Fred Cohen). 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 . ------------------------------ Date: Tue, 13 Dec 1994 18:56:01 -0500 From: GingrichN@aol.com Subject: No, I'm not Newt. AOL's software just makes it easy to pick a `screen name,' any screen name (up to 5 screen names, in fact). For the record, I am Steve Barr, reachable at GingrichN, SarahBrady, BARRST, etc. @aol.com, barrst@iris.uncg.edu, and barrsx@turing.uncg.edu. AOL did seem to go through federal agencies. IRS, [B]ATF, CIA, and FBI were all unavailable. BTW, someone else registered BClinton@aol.com. Just a cautionary note. Now all you need to spoof mail is a credit card (stolen?) and a '10 free hours on AOL' disk. Steve Barr ------------------------------ Date: Wed, 14 Dec 1994 19:09:08 -0800 From: neumann@csl.sri.com Subject: Oral Hackers John Markoff thought the following item might amuse some of you. >From: Mark Colan >Date: 14 Dec 94 12:42:23 ES >Subject: Oral Hackers > >from PC Week, 12/12/94, "Some Outrageous, and Not So Outrageous, Predictions > >PC audio's next push into the world of corporate computing will be dealt a >major blow when a disgruntled layoff victim at General Motors destroys >hundreds of hours of work by running through a floor of cubicles yelling, >"FILE! CLOSE! NO!" The tactic, which will come to be known as oral hacking, >obliterates unsaved work on speech-enabled systems by closing files without >saving. ------------------------------ Date: Mon, 12 Dec 1994 13:37:42 -0500 (EST) From: Gordon Symonds Subject: Technology Under the Weather >From the Dec 11 edition of the Ottawa Citizen: MONTREAL - Myopic weather observation machines installed at Edmonton and Dorval airports to replace human observers as a cost-cutting measure can't tell rain from snow and are being withdrawn from service. Marc Gelinas, a weather specialist at Environment Canada's St. Laurent office, said the machines also cannot tell when there are clouds above 10,000 feet. "At 6:15 PM Friday, it was completely overcast and snowing at Dorval but the automatic weather system issued a report saying there were only scattered clouds at 4,000 feet," Gelinas said. The system at Dorval airport has been providing pilots with inaccurate weather reports since it was installed Nov. 15. Humans will remain on the job at the two airports until the machine can produce accurate weather reports. But the equipment will remain in place at another 48 smaller airports across the country. ------------------------------ Date: 13 Dec 1994 14:10:14 GMT From: "CHARLES R TREW" Subject: WENDY'S STOCK Here's an expensive little mistake: American Stock Transfer and Trust Co. of NY, which handles the stock dividend reinvestment program of Wendy's, recently gave out double dividends to Wendy's shareholders. The company had to reprint and remail account statements to thousands of investors nationwide. I don't know if those receiving dividends via check were given double stuff, if so, that would have generated additional headaches I'm sure. Charlie Trew ------------------------------ Date: Thu, 15 Dec 1994 09:12:22 -0800 From: tlauck@CERF.NET (Tony Lauck) Subject: Re: Formal Methods and Exhaustive testing Those who build computational hardware or software have a responsibility to ensure that their artifacts produce correct results, because these artifacts are used in many applications, some of which are extremely critical to life or property. I can't imagine any valid excuse for shipping a CPU which deterministically gives incorrect results due to a bad algorithm or logical fault in its implementation. Computer arithmetic algorithms and math libraries are simple enough to permit complete verification by a combination of formal methods and exhaustive testing. Here's a story that illustrates the lengths to which it is possible to go. In the late 60's I worked in the PDP-10 group at DEC. Digital had lost a benchmark to its then arch-rival, Scientific Data Systems. It seemed that the PDP-10 square root routine was too slow. I rewrote the routine and speeded it up by 25%, putting the new result on the master disk for subsequent distribution. Part of my speed up included removing unnecessary rounding in the early steps of Newton's method. Being concerned that the resulting code might produce different results from its predecessor, I tested the mantissa processing code exhaustively, verifying in each case that the resulting value was less than one LSB off of the exact answer. I also tested all possible values of the exponent and sign fields. A very little formal work showed that the combined routine was correct. (I would have felt even better if I had had the several months of computer time to test all 2^36 cases directly.) I was prepared to swear that my new routine always gave the same answer as the old. As it turned out, this was NOT true. In exactly one case my new routine did a better job of rounding the square root to single precision. I found this out several years later when Mary Payne called my square root routine "brilliant". My rejoinder was that it was merely "lucky". It seems that Mary had been working to a stricter criteria than mine and wanted the rounding to always give the closest possible value. For a long time, Mary Payne was responsible for Computational Quality at Digital. She consulted in the design of processors or math libraries, or anything else which was likely to result in bad numbers coming out of Digital's computers. It seems most unlikely that the Pentium bug would have gotten past her. ------------------------------ Date: Sat, 10 Dec 1994 18:33:56 -0500 (EST) From: John Gardiner Myers Subject: Re: Mailing-list deadman switch As a postmaster at a large site, I have to say I have a real problem with mailing lists which have this "must actively resubscribe" feature. The feature assumes that all recipients of the list are live humans, who can interpret the resubscribe message and reply. That assumption is not always true. At our site, we encourage users to *not* subscribe to lists directly, instead we prefer to gateway mailing lists into our bulletin board system. This approach saves disk space, mail delivery time, and most importantly administrator time dealing with expired or abandoned accounts. When some list sends out a resubscription request, at least one reader of the associated bboard has to forward it to an administrator, who has to manually respond. This is a waste of expensive staff time. Many times, the subscription just expires and any user who later becomes interested in the list sees what incorrectly appears to be an inactive list. On a different topic: after spending some time composing a reply to the list-looping query in RISKS-16.59, including technical information as to what the standards state various mail agents should do in various situations. In 16.60, I read a reply by Peter da Silva which gave information on the topic that was in fact *completely incorrect*. Later I was horrified to find my name included in an editorial comment as having given a "similar response" on the topic. I suppose this is a RISK of RISKS; by contributing to an edited forum I ended up having my name attached to a position I completely disagree with. I hope the editor will post this retraction: it is my professional position that error (and other) notifications be sent to the envelope return path as the standards specify, that sending them to Errors-to: violates the standards and should not be done. [Yes, indeed. Sorry for the guilt by association. I try wherever possible to prune items with similar messages. Here I elided a little too smoothly. Thanks. PGN] ------------------------------ Date: Tue, 13 Dec 1994 19:26:06 -0500 From: morgan@algorithmics.com (Morgan Jones) Subject: Re: Self-extracting emacs elisp code (Blob, RISKS-16.62) And here is a good example of not RTFM'ing before sending an alarm: >With all this talk about self extracting mail "viruses", a friend showed me >that in emacs (which I use to read mail, along with vm) has the ability to >self-extract elisp code. This feature seems to be turned on by default, and >it not only applies to mail read with emacs, but rather every file visited >(when the feature is on, of course). There are actually two mechanisms at work here. First, emacs supports a per-file variable initialization mechanism. Whenever a file is loaded, emacs scans the end of the file for a special section of "comments" which provide emacs with values to set in certain buffer variables. Enabled by default, this mechanism only allows literal values and so does not constitute any significant risk. In Emacs 19, lisp forms may be included as the value for certain variables, and a special 'eval' construct is allowed which simply evaluates its form. By default, emacs shows you the code and asks if it should be evaluated. The risk is that emacs is a very complicated product and generally requires a fair amount of configuration and customization to be usable by a power user. When a less experienced user sees the "cool stuff" that the power user does, he simple copies the power user's emacs configuration file. Unfortunately, the inexperienced user cannot read the file and so picks up many unwanted changes. If the power user made use of the 'eval' feature, he would probably disable the execution query; the inexperienced user would then be unwittingly susceptible to trojan attacks. Being the primary emacs disciple at my site, I am usually the one responsible for propagating annoying functionality to coworkers. To avoid this problem, I have separated the benign functionality of my configuration to a centrally available file for other users to execute. Dangerous or annoying customizations are stored in my local configuration file which other users no longer need to copy. Morgan W. Jones -- morgan@algorithmics.com Algorithmics Incorporated, Toronto, Canada ------------------------------ Date: Tue, 13 Dec 1994 14:03:25 -0800 From: sidney@apple.com (Sidney Markowitz) Subject: RISKS demonstrates more RISKS in mailing list software I just received something that I guess was sent directly to the RISKS digest LISTSERV remailing address, thus bypassing the normal moderation process of mail sent to risks@csl.sri.com. If I'm correct, those of you not receiving RISKS via the LISTSERV distribution did not see it. It was an ad for some computer hardware. Some people have been sending commercial e-mail messages to lists of mailing list addresses, ignoring the lack of relevance of their ad to the lists' topics. That is called "spamming" and is considered by many on the Internet to be antisocial behavior. This particular message apparently was sent from e-mail address LIONEL GOLDBERG (But read RISK #3 below!). I contacted netcom and was told that they have an explicit policy against spamming from their customers' accounts. RISK #1: The LISTSERV system used by RISKS for automating list distribution on BITNET allows this kind of bypassing of the moderator. RISK #2: If actuary@ix.netcom.com really sent this message to RISKS and a bunch of other mailing lists indiscriminately, complaints to sysadmin@netcom.com can lose him his account. RISK #3: E-mail can easily be forged. The LISTSERV software conveniently removed all traces of the actual path that the message took before it arrived at the list server and was redistributed, so I could not tell if the message was even a crude forgery sent from someone other than the account in the "From" header. So please don't jump the gun in accusing actuary@ix.netcom.com. RISK #4: The ad asks for people to send checks or money orders, no COD or credit cards, to some unknown company for unseen equipment. Anyone want to buy a bridge? RISK #4.9999721: Some of the items listed are Pentiums :-) -- sidney markowitz [Comments from too many of you to name on this, including some who got multiple copies, and some of whom got copies from lists to which they are not even subscribed. netcom has disabled the account. RISKS was not the only list hit. As you all know, the BITNET LISTSERV is wide open to the world. I have no control over what goes gets redistributed, although perhaps one of its wizards will change that soon? Perhaps it should have been set up that ONLY RISKS can cause E-mail to be distributed to the list, but that is not the way it works. Occasionally some overly moronic individual spams our BITNET readers. Perhaps the automated server that we are trying to set up might induce some of you to switch over, although my system does not really need the added burden... Stay tuned. PGN] ------------------------------ End of RISKS-FORUM Digest 16.65 ************************