Subject: RISKS DIGEST 17.78 RISKS-LIST: Risks-Forum Digest Tuesday 20 February 1996 Volume 17 : Issue 78 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator >>>>> [I'm trying to clean up some backlog. But, whenever I am able to >>>>> >>>>> put out MORE issues, the responses accelerate. I'll slow down.] >>>>> ***** See last item for further information, disclaimers, etc. ***** Contents: Possible future risk of virtual reality (Garth Kidd) Credit-Card Scare Tactics [Simson Garfinkel] (Edupage) Risks of not thinking before you submit (Brian Lynch) Risks of having a name (David Crowe) Unix screen-based programs and cursor keys (Ian Chard) Re: Tax Software (Matthew D. Healy) Re: Libel and censorship issues (Steve Bellovin) Re: Risks of using Microsoft Word (David Paulsen, Dan Wing, John J. Males, Alun Jones) Re: Wildcards (Peter T. Breuer, Gene Wirchenko, Jim Thompson, Sean A Dunn, Martin Minow, Steve Kilbane, David Vu, Martin Kealey, Mario M. Butter [2]) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 21 Feb 1996 00:35:29 +0000 (GMT) From: garth@pisces.systems.sa.gov.au Subject: Possible future risk of virtual reality There's a local (Adelaide, Australia) nickname for the long-term effects of immersion games or simulations -- it's the "Tetris Effect". Many people, after playing Tetris for more than an hour straight, report being plagued by after-images of the game for up to days afterwards, an ability to play the game in their head, and a tendency to identify everything in the world as being made of four squares and attempt to determine "where it fits in". Similarly, Descent players suffer from reflexes that tell them that their car should be fitted with various weapon systems ideally suited for educating their fellow commuters; Civilization players are known to dream that Ghandi is demanding technology from them at threat of war; and a friend of mine has been known to be unable to get out of bed because he's "out of movement points". > I think the overall result, though, is that after being in VR-like (or > traditional video game) situations, the individual winds up with better > motion-perception ability. After a long game of net-Descent I find that my visual field of concentration is wider than usual and I "spot" more than usual, but that I misjudge speed and placement, tend to "slide" around corners and bank my head when I turn, and rotate my body rather than my head to see things that aren't in front of me. Aah, human adaptability :). The RISK, of course, is that adaptations suited for one environment can be downright dangerous in others... Garth Kidd, Internet Consultant, Southern Systems, Adelaide, AUSTRALIA garth@pisces.systems.sa.gov.au +61-8-207-7740 (voice) +61-8-207-7860 (fax) ------------------------------ Date: Tue, 20 Feb 1996 17:40:03 -0500 (EST) From: Educom Subject: Credit-Card Scare Tactics [Simson Garfinkel] (Edupage, 20 Feb 1996) Sending your credit card information over the Internet is really no big deal, says Simson Garfinkel, author of a book on Pretty Good Privacy encryption software. "The whole thing about encryption over the Internet is that it's not to protect the customer -- it's to protect the credit-card companies. By law, if there is no signature, the customer is liable for nothing. If there's a signature, they're liable for $50. The reason the credit-card companies want cryptography is to limit their own liability. It has nothing to do with protecting the consumer." And although Netscape Navigator sends a stern message each time a user attempts to send information over the Web, Garfinkel labels the warning just another scare tactic: "Netscape Navigator is printing those messages because they're trying to sell encrypted servers. It's an ad. It doesn't look like an ad, but it is." (*Tampa Tribune*, 19 Feb 1996, B&F3) [Simson is ignoring the hassle factor and other possible side-effects. PGN] ------------------------------ Date: Tue, 20 Feb 96 18:09:35 MST From: "Brian Lynch" Subject: Risks of not thinking before you submit Hummm... Ever have the urge to sign a guest book? Reply to a silly article in USENET or submit something off-color to a mailing list? Think again! Every time you leave your e-mail address somewhere it is like appending "I was at xyz at 1am in 95" to your resume, or whatever else you are applying for. You know the drill, background checks for a job - well, what happens when they search for your name/@ddress? Yikes! This could easily be ported over to anything - school applications, even potential dates. Wouldn't it be easy to add a "User Bio" button that dose a search of the web for a persons email address when you get mail from them? The RISKs are quite apparent. ------------------------------ Date: Tue, 20 Feb 1996 08:54:17 +0000 From: David Crowe Subject: Risks of having a name New Orleans is a strange place, and an incident on a recent flight from there shows how strange... When I got on my American Airlines flight home, my assigned seat was occupied by a man who seemed strangely familiar. We checked boarding passes and we were both assigned to the same seat. Since the flight was almost full, the stewardess took our boarding passes to sort out what was wrong. She came back 10 minutes later with a strange look on her face. "Which of you is Mr. D. Crowe?" she asked. Both of us answered "Me". Then I realized where I had seen my seatmate before. He is not only another D. Crowe, but another David Crowe, and also lives in Calgary. We had had lunch together once, a while ago, due to number of misdirected phone calls and other mistakes that had been made due to our common names. I guess the reservations computer thought that it was being smart, and that it was fixing the double issuance of a boarding pass! David Crowe crowed@cadvision.com ------------------------------ Date: Wed, 21 Feb 1996 02:31:43 GMT From: ian@tanagra.demon.co.uk (Ian Chard) Subject: Unix screen-based programs and cursor keys I've just had a rather alarming experience while using Linux's "cfdisk" program (for those that don't know, cfdisk is a disk partitioning tool, and it is screen-oriented, requiring the use of the cursor keys). When I tried to move around the screen, the program didn't understand the control sequence generated by the cursor keys on my terminal, and as one of the characters in the sequence was the letter D, one of my partitions suddenly disappeared. No damage was actually caused by this (I killed the process rather than trying to exit, as heaven knows what further attempted cursor movement would have done), but the risks are obvious. It seems to be common that terminals attached to Unix systems have non-functional cursor keys, and critical applications like disk partitioners should take note. Ian Chard ian@tanagra.demon.co.uk +44 161 434 6492 ------------------------------ Date: Tue, 20 Feb 1996 13:40:46 -0500 From: healy@seviche.med.yale.edu (Matthew D. Healy) Subject: Re: Tax Software (Re: PGN, RISKS-17.75) A year or so ago, some major accounting firm ran a half-dozen test cases through every commercial tax preparation software they could get their hands on -- including some aimed at professional accountants. No two programs gave identical results, and some of the differences were quite substantial. After analyzing the differences, they concluded that it wasn't the software firms' fault -- the rules were just too vague and inconsistent. This had always been true, but the conversion to computer programs exposed the problems to detailed scrutiny in a way that had not previously been possible. [That was in RISKS a year ago. PGN] This prompted a columnist in some computer mag -- I forget which one -- to propose that the IRS be required each year to release into the public domain source code in some commonly-used high-level language that would constitute a legally-binding algorithm for computing one's income taxes. All you'd have to defend in court would be the data you supplied, as the program would be considered binding on everyone. Matthew.Healy@yale.edu Postdoc (& WebMaster), Center for Medical Informatics, Yale School of Medicine http://paella.med.yale.edu/~healy/matt_healy.html ------------------------------ Date: Tue, 20 Feb 96 16:40:13 EST From: smb@research.att.com Subject: Re: Libel and censorship issues (Reynolds, RISKS-17.77) One more important qualifier: only statements of fact can be considered libel, not expressions of opinion. Clearly there is some room for interpretation here -- if I call my least favorite politician crazy, I'm expressing an opinion, while if his/her psychiatrist says the same thing it might be perceived as a medical diagnosis. And, of course, libel laws differ around the world -- the net is not a domestic U.S. phenomenon. --Steve Bellovin ------------------------------ Date: Tue, 20 Feb 96 12:40:33 PST From: david@tower.tandem.com Subject: Re: Risks of using Microsoft Word (Gebe, RISKS-17.76) The problem described as "Risks of using Microsoft Word" probably actually resides in the web browser being used for Thomas' cruising. If that web browser is storing a history of sites visited and passwords in a file, and later deleting that file, the file's data may live on and be accessed when another application re-uses that disk space. Perhaps MS Word should be initializing the disk space that it allocates, but the web browser should probably be doing a better job of purging old data if it contains information that needs to be secure. A similar situation arose for me in a previous job. A customer decided to dump an isam-like database file to a printer. He called our (not Tandem's) customer service in a panic because the database file had some sort of "high-severity failure" message in the database file. As it turned out, the isam database file creation utility had allocated some 4096 bytes of disk space without writing anything to that space, and it re-used a chunk of disk that previously contained part of a rather old defect report from our QA department. We altered the database file creation utility so that it would write nulls out to the disk rather than just setting the eof. David Paulsen, Software Designer, Tandem Computers Incorporated paulsen_david@tandem.com or david@tower.tandem.com ------------------------------ Date: Mon, 19 Feb 1996 14:22:42 -0800 (PST) From: WING@TGV.COM (Dan Wing) Subject: Re: Risks of using Microsoft Word (Gebe, RISKS-17.76) If you're running Win95, you may want to install Microsoft's recently released "Windows 95 Service Pack 1". This includes an OLE32 update, which appears to address this problem: [...] when such a document file is viewed by using [sic] Windows Notepad (for example), it might be possible to see pieces of information from the previously deleted files. This could pose information security or privacy concerns if you distribute electronic versions of files created using these applications. [...] See http://www.microsoft.com/windows/software/servpak1/moreinfo.htm for more details. -Dan Wing, wing@tgv.com [Also noted by Howard Chalkley , GST Technology Ltd, Huntingdon PE17 4LG, UK +44 1480 496789. PGN] ------------------------------- Date: Mon, 19 Feb 1996 23:14:30 +1000 From: johnm@physiol.su.oz.au (John J. Males) Subject: Random information in Microsoft Word Files (Gebe, RISKS-17.76) I use a Macintosh running Word 5.1 at university. This computer is used by many people. I have noticed that all manner of text appears in Word files that have been edited on this computer. It seems that the text that "appears" in the Word files are remnants of old files (seemingly other Word files) saved on the hard drive - I do not think it was possible for the information that I found in my documents to have been present in RAM at the time I was editing these documents. However, if you open these documents in Word, none of this added text is visible. I did not think anything of this when I saw it, but it seems that it was not an isolated problem. The RISK is obvious. What is Microsoft Word doing in this instance? John J. Males johnm@physiol.su.oz.au http://www.usyd.edu.au/~jmales ------------------------------ Date: Mon, 19 Feb 1996 10:17:01 -0600 (CST) From: Alun Jones Subject: Re: Risks of using Microsoft Word (RISKS-17.76) Thomas Gebe notes that his Word files seem to contain extraneous information that he could read quite easily in a text editor. This isn't a new risk, either to Risks readers (anyone here remember similar problems with Prodigy?), or to Microsoft; last week's "Service Pack 1" for Windows 95 (http://www.microsoft.com/windows/software/servpak1/sphome.htm) included a fix for just this problem. Microsoft openly admit "This could pose information security or privacy concerns if you distribute electronic versions of files created using these applications" ("these applications" include Word, Excel and PowerPoint, and may also include other non-Microsoft programs that use the OLE functions for file storage). The notes with the service pack mention that this is not a problem under Windows NT, since the operating system automatically clears disk space that was used by deleted files. The notes also go on to recommend that if you are using non-95 versions of these programs, you should obtain the "C" releases of these products (although the note doesn't mention where to find patches). I wonder if there might be a risk in posting to risks before checking with the companies involved for fixes? As a software author myself, I frequently find myself rushing to put out fires created by someone reporting a security bug in my program that was found, and immediately fixed, over a year ago. The reporting of risks in computing is important (otherwise I wouldn't be reading this group!), and yet I wonder if we shouldn't try more to give a "right to reply" to some of the parties mentioned. On an amusing side-note, it is interesting to see how many of the respondents in RISKS-17.75 to the "Wildcards" article suggest that the wildcard problems would be fixed if only there was a DOS standard library for expanding wildcards. One even expressed surprise that this wasn't the situation under DOS. For those of you who weren't reading 17.75, there _are_ standard wildcard expansion functions, accessed through DOS (not BIOS, as I mistakenly wrote) interrupt 21H, subfunctions 4EH (find first file) and 4FH (find next file). The risk? Again, making a value-judgement on limited information; also known as ASS-U-ME. Alun ------------------------------ Date: Mon, 19 Feb 1996 09:05:33 +0100 (MET) From: "Peter T. Breuer" Subject: Re: Wildcards (RISKS-17.75) It occurs to me to ask if there is any possible protection against the combination of one's own VR trained reflexes and a common shell feature: filename completion. I have an area of my filesystem neatly divided into three directories, "in", "pending" and "out". When I have dealt with an "in" file, it goes into "pending". I type "mv foo ../p" and let filename completion do the rest, banging on the return key for emphasis. This works fine until I miss one dot with a single file named (say) "in/peter" hanging around. Then the expansion is to "mv foo ./peter" and my trained reflex hits the return key too fast to save peter (joke). Should I sue the shell designers for failing to protect me against my own normal human learned reflex pattern? Or is it my fault for not taking the precaution of letting a tyro drive my shell for me after too much typing, like the airline pilot who gets his wife to drive him home in case his reflexes do the right thing in the wrong situation? As a sometime software engineer, this makes me realize that human beings are awkward processes to program for. Driving a computer by translating my intentions to its command structure is a risky business. Peter T. Breuer Departamento de Ingenieria de Sistemas Telematicos, Universidad Politecnica de Madrid, Escuela Tecnica Superior de Ingenieros de Telecomunicacion, ------------------------------ Date: Sat, 17 Feb 1996 21:07:13 GMT From: genew@mindlink.bc.ca (Gene Wirchenko) Subject: Re: Wildcard inconsistencies in Windows 95 (D'Oliveiro, RISKS-17.73) >... In Windows 95, the "?" wildcard is treated inconsistently in file >specifications: sometimes it means "exactly one character", and other times >it means "at most one character". It has been like that since CP/M that I know of. This is not something new. Another related problem is that "dir &*", where "&" stands for a prefix (as in "dir risk*"), lists all extensions i.e. functions as "dir &*.*". To get around this one, use "dir &*.". Gene Wirchenko ------------------------------ Date: Tue, 20 Feb 1996 06:49:35 -0600 From: jthompso@netcom.com (Jim Thompson) Subject: Re: wildcards (Armstrong, RISKS-17.76) It looks as if Access 2.0 is applying regular-expression matching rules instead of wildcard-matching rules. In a regular expression, the '?' indicates a match of zero or one occurrences of the preceding expression, in this case '9'. Note also that in a regular expression, the '.' is also a special character, matching anything but newline. So if Access 2.0 is indeed using regular-expression rules, then the kill command you tested should also delete, for example, the file TEST9-TXT. Jim Thompson jthompso@netcom.com [regular expression explanation also offered by Mark Pappin . PGN] ------------------------------ Date: Mon, 19 Feb 96 22:47:15 From: Sean A Dunn Subject: Re: Wildcards For what it's worth, a way of reducing the risk of deleting more or less than necessary when you need to hit only a subset of files in a directory: - create a sub-directory called TEMP (you'll know if it already exists) - MOVE the relevant file to the sub-directory (this should only involve directory updates so it usually very quick) - examine at your leisure - delete everything in the sub-directory - get rid of the sub-directory Why trust the software? Play it safe(r). Sean Dunn, Wolverhampton, England sean@lilydale.demon.co.uk ------------------------------ Date: Sat, 17 Feb 1996 19:13:26 -0800 From: minow@apple.com (Martin Minow) Subject: Re: Wildcards (Stolz, RISKS-17.75) If I may step back a bit from the Unix/DOS arcana, perhaps the real risk is the notion that existing files are selected by typing their names. On the Macintosh, existing files are selected by clicking on their names or icons in a dialog or window. (It is possible to select files by typing the name, or part of the name, into the Find File application window, but this is not the primary method.) Also, on the Macintosh, file deletion is a two-step process: dragging a file's icon to the trash makes it unavailable, but the actual bits are not recycled until the trash is explicitly emptied. Unix, and DOS offer considerable power to their users, and require an equivalent amount of understanding of the inner workings of the operating system. This may be unreasonable in an era of pervasive personal computing. Martin Minow minow@apple.com [We received an enormous number of responses to the Stolz message. I have selected just a few, trying perhaps hopelessly to avoid duplication. But, you may give up on this issue of RISKS if you have already had enough. PGN] ------------------------------ Date: Mon, 19 Feb 1996 09:09:54 GMT From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Subject: Re: Wildcards (Stolz, RISKS-17.75) I won't get into the debate about whether UNIX shell wildcard expansion is a good idea. Instead, I'll point out another risk. In at least one book for new UNIX users, I have seen wildcards introduced as though the program in the example was expanding them, rather than the shell. The book in question claimed "all UNIX commands take wildcards." If you start out with misinformation, is it any wonder that neophytes get bitten? ------------------------------ Date: Tue, 20 Feb 1996 13:07:48 +1000 From: David Vu Subject: Re: Wildcards (Stolz, RISKS 17.76) It was said that wildcards are implemented differently under different operating systems, DOS, Win95, Unix, VMS, etc. And the risk of deleting files you don't want to delete is also present in Unix. Otto Stolz points out that 'rm x*' will remove files beginning with 'x' but not directories or files under directories beginning with 'x'. But, in the FTP file transfer program, when connected to a Unix ftp server, the command 'mdel x*' will delete all files beginning with 'x' and ALL files in directories beginning with 'x'. The directories themselves are not removed though. I am not sure how the FTP server removes files; those with access to the ftpd source might want to comment. David ------------------------------ Date: Sun, 18 Feb 1996 14:05:09 +1200 (NZST) From: martin@kcbbs.gen.nz Subject: Re: Wildcards (Stolz, RISKS-17.75) > wildcard inconsistency: as a program does only see the expanded > parameter list, it does not know whether a wildcard string was > involved (and if so, which one). How can this be considered "inconsistent"? Inconsistent with what? (Inconsistent with DOS maybe??) The Unix shells always expand wildcards to pre-existing files (some of which are directories); in that they are perfectly consistent. It just happens that in a few cases, this isn't what might be considered preferable. However in the other 95% of cases, it means one less thing for the program to have to deal with. > Hence, depending on the options specified, the Unix ls command > (the equivalent of the DOS dir command) lists more files than ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the rm command (the Unix equivalent for the DOS del command) > would remove on account of the same wild-card string. This is the inconsistency, if there is any: the "ls" command by default expands the contents of directories one level, while the dos "dir" command does not. "ls -dl" would be a closer equivalent to "dir". A more appropriate command to use to test what "rm" is going to do would be "echo". The source of most complaints about shell-based wildcard expansion revolve around not being able to have two wildcard parameters, one of which is used to match existing filenames while the second is used to generate a list of new names based on the first set. While this is a valid point, the cases where this would be useful are actually quite few, can be accommodated in other ways - just differently from how DOS would do it. The risk? Assuming that wildcard MATCHING of filenames is what you actually want (rather than wildcard GENERATION of filenames), and traditionally having a notation that does not distinguish between them. -Martin ------------------------------ Date: Sat, 17 Feb 1996 12:10:12 -0500 (EST) From: "Mario M. Butter" Subject: Re: Wildcards (Stolz, RISKS-17.75) > In VM/CMS, the program gets the wildcard string, and it can use a central > routine (LISTFILE) to expand this string. I think, this is the best solution. This is not an inconsistency in in Unix, rather a misunderstanding in the way you use the `ls' command. If you pass a directory name to the `ls' command, it will list the contents of that directory. You can prevent this with the `-d' option, in which case it *will* only display the directory name. Passing this same list to the `rm' command will not delete the directory, which is the default behaviour for `rm'. Passing the `-r' option to `rm', will however delete all the files in specified subdirectories. So, under your example, you *can* delete all the files shown in the `ls' just by passing the `-r' option to `rm'. Mario Also noted by thorinn@diku.dk (Lars Henrik Mathiesen) and amos@nsof.co.il (Amos Shapir). PGN] ------------------------------ Date: Sat, 17 Feb 1996 09:29:02 -0500 (EST) From: "Mario M. Butter" Subject: Re: Wildcards (Wei-Yuen Tan, RISKS-17.75) This difference between filename globbing predates MicroSoft Windows. In older versions of DOS, the command 'dir *' assumes a '.*' extension, while 'del *' assumes no extension. I always assumed each program had it's own (and different) globbing routine, and never used a 'dir' command to verify what the 'del' command would delete. I always just made sure I had a couple of backups before I cleaned my drive. :) More recently, I use Linux to maintain my DOS filesystems. ;) Mario M. Butter mbutter@tower.clark.net gaummb@fnma.com ------------------------------ Date: 14 February 1996 (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) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for further information] 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, nonrepetitious, and without caveats on distribution. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. By submitting an item that is accepted for publication in RISKS, the author grants permission for unlimited noncommercial public distribution and redistribution in electronic and print form. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp ftp.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://ftp.sri.com/risks PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest, see the INFO file at RISKS-Request (one-line message INFO noted above). ------------------------------ End of RISKS-FORUM Digest 17.78 ************************