Subject: RISKS DIGEST 16.85 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 24 February 1995 Volume 16 : Issue 85 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, etc. ***** Contents: [Note: ACM Computer Science Conference in Nashville NEXT WEEK] Another police sting based on a freebie video offer (Clive D.W. Feather) More Security Problems on the Internet (Edupage) "E-Mail Security" by Schneier (Rob Slade) *BUGS in Writing: [...] Debugging Your Prose*, by Lyn Dupre (Bob Donegan) Re: CERT Advisory CA-95:04.NCSA.http.[...]vulnerability (Timothy Hunt) Re: Perfect (?) Office Bug can cause harm (Keith Schengili-Roberts) Re: Perfect (?) Office Bug can cause harm (Jerome Whittle) Re: Sparc10 keyboards and resetting the CPU (Tarl Neustaedter) Re: Major file corruptions (George C. Kaplan) Re: Major file corruptions (George Buckner) Re: Major file corruptions (Kenneth Albanowski) Re: JUDGES-L (David Stodolsky) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 22 Feb 1995 07:33:49 +0000 (GMT) From: "Clive D.W. Feather" Subject: Another police sting based on a freebie video offer [Not really RISKS related, but interesting because stings of this type seem to becoming a common practice. But soon this will be happening on the information superhighway. PGN] Drawn by invitations in the name of a fictitious market-research company, 31 ``elusive criminals'' responded in person to a drawing for a year's free use of telly facilities. After filling out questionnaires on their viewing habits, they were then arrested. ``Operation Trick or Treat'' turned out to be a Trick. (For you anagram freaks, the bogus company name, Mison Giewold, is an anagram of the name of Detective Constable Simon Weigold, the officer who organized the sting.) [Source: ``Prize draw proves winner for police" -- by Nigel Bunyan, *The Electronic Telegraph*, 22 Feb 1995; inquiries to its editor at . Abstracted by PGN.] ------------------------------ Date: Thu, 23 Feb 1995 20:35:30 -0500 From: info@ivory.educom.edu (Edupage) Subject: More Security Problems on the Internet (Edupage, 23 Feb 1995) The Computer Emergency Response Team has issued a public warning on a vulnerability in some 20 commonly used E-mail programs that run on Unix operating systems. The advisory said the latest discovery could allow a hacker to ``read any file on the system, overwrite or destroy files." The ultimate solution to these recurrent security problems, says Purdue University professor Eugene Spafford, is for consumers to demand better security features from software manufacturers. In the absence of improved software, "are we going to continue seeing problems? You bet." (Wall Street Journal 2/23/95 B8) [Spaf really said that's the ULTIMATE, eh? That's as good as it can get? Wow! We are really in for a bad time. PGN] ------------------------------ Date: Fri, 24 Feb 1995 13:27:32 EST From: "Rob Slade, Social Convener to the Net" Subject: "E-Mail Security" by Schneier BKEMLSEC.RVW 950127 "E-Mail Security", Bruce Schneier, 1995, 0-471-05318-X, U$24.95/C$32.50 %A Bruce Schneier schneier@counterpane.com %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 1995 %G 0-471-05318-X %I John Wiley & Sons, Inc. %O U$24.95/C$32.50 416-236-4433 fax: 416-236-4448 800-CALL-WILEY %O 212-850-6630 Fax: 212-850-6799 Fax: 908-302-2300 jdemarra@jwiley.com %P 365 %T "E-Mail Security" This is the third work that I have seen on the PGP (Pretty Good Privacy) text encryption and authentication system. (I understand that at least two more are in the works.) It is also the first to truly present the general concept of email security by covering the only other realistic option--the Internet Privacy Enhanced Mail (PEM) standard and (Mark) Riordan's Internet Privacy Enhanced Mail (RIPEM) implementation. The book divides roughly into quarters discussing background, practical use, the PGP documentation, and the PEM RFCs. The work is considerably different, in style, to the Stallings (BKPRTPRV.RVW) and Garfinkel (BKPGPGAR.RVW) efforts. Those books, while not obtuse, were still written with a technical audience in mind. Schneier's work, while definitely showing the expertise he demonstrated in "Applied Encryptography" (BKAPCRYP.RVW), is clearly aimed at the general, non-technical reader. (Interestingly, while he *does* tell you where to find the RC4 algorithm posting, he *doesn't* mention the loophole recently pointed out in the Clipper "Skipjack" algorithm.) The straightforward style lulled me into thinking that chapter one was too long. It isn't: Schneier makes the important point that, for it to be *truly* effective, encryption must be used on *all* correspondence, even trivial items. So well crafted is his argument that it would be difficult to reduce the chapter by so much as a paragraph. Schneier uses this argument to good effect in pointing out some of the major deficiencies in the two systems. PGP is awkward to use, and PEM may use incompatible algorithms. Surprisingly, he does not emphasize (though he does mention) what is probably the major problem with each--the inability to use the same system within and outside of the United States. The PGP fiasco is too involved to get into here (see the Garfinkel work for details) and there is not yet an "international" implementation of PEM (although there may soon be an "authentication only" version available). This won't help you design your own algorithm, but it is definitely for any user of email, manager of communications systems, or student of privacy and confidentiality. copyright Robert M. Slade, 1995 BKEMLSEC.RVW 950127 DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 ------------------------------ Date: Wed, 22 Feb 1995 18:01:13 -0500 (EST) From: Bob Donegan Subject: *BUGS in Writing: A Guide to Debugging Your Prose*, by Lyn Dupre *BUGS in Writing: A Guide to Debugging Your Prose*, by Lyn Dupre ISBN: 0-201-60019-6 $19.95 (price subject to change), 649 pp., paperback [And WHAT, might you ask, does this have to do with RISKS? Well, can you think of any bugs in computer systems that have resulted from bugs in writing? We've seen quite a few in RISKS. And besides, this is a terrific book. PGN] *BUGS in Writing*, written with verve and wit, may be the first book on writing that people read for sheer fun. Unlike traditional style manuals, which present huge hierarchical rules bases (and which hardly make for amusing reading), *BUGS* presents an alternative, intuitive way of looking at written language that is based on the concept of ear: the ability to hear, without analysis, whether a given work order, sentence, or term is correct. *BUGS* explores problems that writers face, and explains how to rid your prose of these bugs. Designed for easy browsing, *BUGS* comprises 150 independent and easily digestible segments, resembling a daily newspaper column and presented with an unusual, appealing, inviting design. Dupre not only tells you about good writing -- she also demonstrates it for you, conveying simple principles for lucid writing by numerous, intriguing, and frequently hilarious examples that are classified with the bugs system: Bad, Ugly, Good, or Splendid. *BUGS* was developed for anyone who writes and who works with computers, including computer and other scientists, students, professors, business people, programmers, and technical writers. Rather than subjecting yourself to the pain and tedium of wading through a reference book on English grammar, you can pick up *BUGS*; you will immediately find yourself browsing interesting and amusing material. While you are enjoying yourself, you will be tuning your ear. As a result, you will write lucid prose that communicates your ideas. ------------------------------ Date: Thu, 23 Feb 95 11:20:36 +0000 From: "Timothy Hunt [Assistant Unix Systems Manager]" Subject: Re: CERT Advisory CA-95:04.NCSA.http.daemon.for.unix.vulnerability This is a warning about poor distribution of fixes for security holes. In several locations on the 'net I have found the warning about the security hole in NCSA httpd 1.3. The fix they suggested was only to change the default string lengths, but didn't include the patch to perform the functionality of strsubfirst(). While this will prevent any current attack programs from gaining access, only a minor change would be necessary to attack the slightly modified httpd (I think!). This means there are probably a good many httpd daemons out there that are still vulnerable, yet the administrators think they are now secure. Timothy J. Hunt, The Institute of Cancer Research, Royal Marsden NHS Trust, Downs Road, Sutton, Surrey, England SM2 5PT +44 (0)181 642 6011 x3312 ------------------------------ Date: Wed, 22 Feb 95 15:21 WET From: kschengi@interlog.com (Keith Schengili-Roberts) Subject: Re: Perfect (?) Office Bug can cause harm (Gillard, RISKS-16.83) I read this submission to RISKS with some amusement. This particular problem is not new to the WordPerfect portion of Novell's Perfect Office -- in fact WordPerfect is far from being the only culprit in leaving behind stray ~*.tmp files. In the course of its operations, Windows and many Windows applications often write files with a ~*.tmp filename to the \TEMP directory listed in the AUTOEXEC.BAT file via the SET TEMP= command. Windows normally removes these files automatically when you exit Windows. If Windows crashes, or if you turn off your computer before exiting gracefully from Windows, these files get left behind, and are not erased the next time you start Windows. The accumulation of ~*.tmp files not only will take up hard drive space, but can interfere with the operation of Windows and Windows applications. Many a mysterious General Protection Fault I've run across on other people's computers have been attributed to an accumulation of ~*.tmp files on their hard drives. The best thing to do is to erase these ~*.tmp files from your hard drive as often as possible. Many people throw in a line within their AUTOEXEC.BAT files which automatically go to the directory where ~*.tmp files are stored, and delete the contents of that directory before launching Windows. This must be done from DOS, rather than from within Windows, as Windows does not take kindly to the attempted erasure of ~*.tmp files it is currently using. If you are not sure where your ~*.tmp files are stored, type SET from the DOS prompt, and the SET TEMP= will tell you which directory to check. If no SET TEMP= line appears, the ~*.tmp files will reside in your \WINDOWS directory. My only criticism of WordPerfect (going back to version 5.1 for Windows to the current 6.1 release) in this matter is that they consistently leave behind more ~*.tmp files than most of the other Windows programs I have used. I still prefer WordPerfect over most other wordprocessors however, so I suffer with the problem and just erase the stray ~*.tmp files it leaves behind. Keith Schengili-Roberts, The Computer Paper, 99 Atlantic Avenue #408, Toronto, Ontario M6K 3J8 CANADA kschengi@interlog.com http://www.wimsey.com:80/tcp ------------------------------ Date: Wed, 22 Feb 95 08:19:00 cst From: "Whittle, Jerome SMSgt" Subject: Re: Perfect (?) Office Bug can cause harm (Gillard, RISKS-16.83) Unless Novell is really bad about it, I don't think Perfect Office is the only guilty party. We use Microsoft Office here and have the same problems. Actually I think that it is a Windows problem. One of the things I do when I "tune-up" someone's computer is look for temp files. I search using File Manager with a Search For: ~*.*. I have literally found megs of temp files clogging up hard drives. The user is usually to blame. The temp files should be deleted when the user closes the application or shuts down Windows *properly*. If they just turn off the power switch while Windows is still on the monitor, temp files won't be deleted. In other words, tell them not to hit the power switch until they see C:\. (Another problem with not shutting down Windows properly is there will be lost clusters all over the place on the hard drive. Using CHKDSK /F or SCANDISK, I've recovered up to 50 megs of hard drive space!). If they don't have a SET TEMP=C:\TEMP (or something similar) statement in their AUTOEXEC.BAT, temp files will just dump all over the place. Also, there better be a TEMP (or similar) directory or the same will happen. Jerry Whittle, Belleville, Illinois, USA jwhittle@amclg.safb.af.mil ------------------------------ Date: Tue, 21 Feb 1995 23:56:08 -0500 From: tarl@tarl.net (Tarl Neustaedter) Subject: Re: Sparc10 keyboards and resetting the CPU (Puchol, RISKS-16.83) > It has happened to me several times now that I inadvertently knock the > keyboard cable of the Sun SPARCstation 10 I work on these days. Most of the > times, the result is a complete and instantaneous crash of the machine. Actually, this is a feature. I know, it doesn't sound like a feature. And there are more ways to come to grief by this feature than just mentioned - most notable being the well-intentioned conservationist who powers off an ASCII terminal being used as a sun server console. The agonized screams from the users down the hall usually alert the conservationist as to his impending fate. (See also: http://pond.cso.uiuc.edu/ducky/docs/jimbo/raptor.html) It doesn't actually cause a crash. Since time immemorial (long before I started working with sun serial drivers), a BREAK condition on the console line has been an attention signal telling a Sun to jump into its prom. Unplugging a serial (async) line generates a BREAK condition. Usually, you can recover by typing "go" after you plug the cable back in. The reason it is a feature; Occasionally a user will do something he regrets (certain programs which clobber the keyboard or simply won't exit should not be run on the console), and the user needs some way to regain control of his system. Unlike PCs, UNIX resents being powered off. It wants to be politely shut down first. If you forget often enough, UNIX will take it's revenge on you by eating your file system. Hence this escape into PROM. On a normal ascii line, the only safe condition to detect is a "BREAK" - everything else having been assigned functions by Gnu EMACS. On a keyboard, where we aren't limited by ASCII, the "STOP-A" combination is normally used. But "BREAK" serves the same purpose, and will sometimes work when STOP-A won't (send me email if you want the grody details). Once you have gotten back into the prom, you can "sync" the filesystems and reboot. If you _really_ want to disable this functionality, you could find the call to abort_sequence_enter() at the end of zsa_xsint in zs_async.c, and NoOp it out. This keeps STOP-A/L1-A functionality (called from kbd.c) while disabling the "BREAK" functionality. It helps to be handy with kadb. But caveat emptor - Murphy's law guarantees that as soon as you disable this functionality, within the next week you will desperately need it. Tarl Neustaedter tarl@tarl.net [home], tarl@east.sun.com [work] Ashland, MA, USA http://tarl.net/tarl [Rather similar comments also from nick@cimio.co.uk (Nick Waterman), Craig_Everhart@transarc.com, "Rory O'Donnell" , Keith Price , Mark.Kantrowitz@GLINDA.OZ.CS.CMU.EDU, Marc Horowitz , edward@igate1.HAC.COM (Ed Bruce), and maybe others whose SUBJECT: field said only ``Re: RISKS-16.84" -- which means there is a chance that I will NEVER look at those messages, unless perhaps I happen to do a search on some keyword. Note: there is a WARNING to that effect in the INFO message. PGN] ------------------------------ Date: Fri, 24 Feb 1995 12:39:40 +0800 From: gckaplan@sunspot.ssl.berkeley.edu (George C. Kaplan) Subject: Re: Major file corruptions (Preston, RISKS-16.84) Charles M. Preston's story of corrupted files (in RISKS-16.84) sounds like a situation I once saw that was traced to a flaky disk controller. Sometimes one or more bits would be cleared somewhere in the file. Since it was the "0x20" bit, we first noticed it when random scattered letters were capitalized in text files. Sometime later, presumably after buffers had been flushed, the affected files would be back to normal. The service tech didn't quite believe us, but he replaced the disk controller board, and the problem went away. George C. Kaplan gckaplan@ssl.berkeley.edu 1-510-643-5651 ------------------------------ Date: Fri, 24 Feb 95 15:45 EST From: George Buckner Subject: Re: Major file corruptions I've discovered a tendency for PKUNZIP to report corrupt files when I run it from a DOS shell while Windows is running. This problem goes away if I close Windows first. (No this isn't a fix or an explanation, but my temporary work-around). George Buckner ------------------------------ Date: Fri, 24 Feb 1995 15:49:27 -0500 (EST) From: Kenneth Albanowski Subject: Re: Major file corruptions Charles Preston asks "what type of problem, other than malicious programming, could cause these symptoms?", in regards to an on-line service occasionally serving up damaged files. The possible reasons for such behaviour are numerous, and it aids no-one to call up the specter of a rouge programmer or "hacker", if such a thing is not known to be true. This is a risk that is now being run by everyone providing an electronic service: an accusal of being "hacked", or of "downloading the users hard disk in secret", or of "damaging files for unknown purposes", (just to name a few,) carries a large weight in the press, and is potentially difficult to fight. I believe Charles is talking about the CompuServe Information Service, which I have heard some small comments about infrequent damage to downloaded files. The behaviour is supposed to be quite uncommon, and goes away on a repeat of the transfer. Of course, Charles could be talking about any large service that provides files for download. Anything from a damaged disk drive to a fluky controller card to a out-of-tolerance CPU to a buggy program could cause these problems, and I know of no company that is immune to such things. Lastly, yes, since the file-transfer checksums matched, having a secondary checksum (in this case, actually a CRC provided by PKZIP) would certainly prove useful. That's why PKZIP does it, and why CRCs are in common use. This also points out the risk of not verifying data integrity on all levels. Presumably a CRC check used at some stage in the service's computer would have detected the problem earlier. Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126) ------------------------------ Date: Wed, 22 Feb 95 19:32:08 +0100 (CET) From: david@arch.ping.dk (David Stodolsky) Subject: Re: JUDGES-L (da Silva, RISKS-16.83 on Stodolsky, RISKS-16.82) Looks like Peter da Silva was confused by the "Cancel Messages: Frequently Asked Questions Part 2" post, a forgery meant as a joke. The List has released a single informational post, a single time. It was developed with contributions from leading Usenet administrators, some of whom have chosen to remain anonymous. When the latest version was approved, via a consensus decision making process, there were about a dozen leading administrators subscribed, and under the rules, anyone of them could have blocked its release, or tried to, thus precipitating a vote. This did not occur. It was a consensus document. (The forgery was, unfortunately, taken seriously by all too many, including the Italian EFF. This perhaps is an indication of the need for informational posts on this topic.) The authentic document starts with a summary: Cancel Messages: Frequently Asked Questions (FAQ). Ver. 2.0 Summary: You can protect your reputation as a information source by cancelling articles posted under your name as soon as you discover that they are erroneous. Cancelling other's articles, however, can expose you, your site, and the Net as a whole, to serious threats. The sender should be notified when articles need to be cancelled. Disputes or doubtful cases can be directed to the Judges' List for resolution. The List is open to anyone who agrees to follow the rules adopted through the List's consensus decision making process. The List is not confidential, that is, it can be located by a LISTSERV search. It is also open to review by the public. A review command to LISTSERV@UBVM.cc.buffalo.edu will yield the settings and membership of the List. This will show, among other things, that anyone may send mail directly to the List: There is no editor who must approve messages. Since the List now offers confidential dispute resolution, the continued dissemination of messages via mail-to-news gateways, etc. was deemed inappropriate. This question, however, continues to be debated. Information about the NetNews Judges (TM) List appeared in the _New Scientist_ magazine at the end of last year. It is also discussed in the most recent issue of _Matrix News_. I was also interviewed recently by a reporter from _The Chronicle of Higher Education_ about the List. David S. Stodolsky, PhD * Social * Internet: david@arch.ping.dk Tornskadestien 2, st. th. * Research * Tel.: + 45 38 33 03 30 DK-2400 Copenhagen NV, Denmark * Methods * Fax: + 45 38 33 88 80 ------------------------------ Date: 6 February 1995 (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. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS 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 and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 16.85 ************************