The RISKS Digest
Volume 17 Issue 78

Tuesday, 20th February 1996

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

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]
Info on RISKS (comp.risks)

Possible future risk of virtual reality

<garth@pisces.systems.sa.gov.au>
Wed, 21 Feb 1996 00:35:29 +0000 (GMT)
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)


Credit-Card Scare Tactics [Simson Garfinkel] (Edupage, 20 Feb 1996)

Educom <educom@elanor.oit.unc.edu>
Tue, 20 Feb 1996 17:40:03 -0500 (EST)
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]


Risks of not thinking before you submit

"Brian Lynch" <blynch@acs.ucalgary.ca>
Tue, 20 Feb 96 18:09:35 MST
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.


Risks of having a name

David Crowe <crowed@cadvision.com>
Tue, 20 Feb 1996 08:54:17 +0000
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


Unix screen-based programs and cursor keys

Ian Chard <ian@tanagra.demon.co.uk>
Wed, 21 Feb 1996 02:31:43 GMT
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


Re: Tax Software (Re: PGN, RISKS-17.75)

Matthew D. Healy <healy@seviche.med.yale.edu>
Tue, 20 Feb 1996 13:40:46 -0500
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


Re: Libel and censorship issues (Reynolds, RISKS-17.77)

<smb@research.att.com>
Tue, 20 Feb 96 16:40:13 EST
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


Re: Risks of using Microsoft Word (Gebe, RISKS-17.76)

<david@tower.tandem.com>
Tue, 20 Feb 96 12:40:33 PST
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


Re: Risks of using Microsoft Word (Gebe, RISKS-17.76)

Dan Wing <WING@TGV.COM>
Mon, 19 Feb 1996 14:22:42 -0800 (PST)
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 <howard@gst-soft.demon.co.uk>,
     GST Technology Ltd, Huntingdon PE17 4LG, UK  +44 1480 496789.  PGN]


Random information in Microsoft Word Files (Gebe, RISKS-17.76)

John J. Males <johnm@physiol.su.oz.au>
Mon, 19 Feb 1996 23:14:30 +1000
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


Re: Risks of using Microsoft Word (RISKS-17.76)

Alun Jones <alun@texis.com>
Mon, 19 Feb 1996 10:17:01 -0600 (CST)
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


Re: Wildcards (RISKS-17.75)

"Peter T. Breuer" <ptb@dit.upm.es>
Mon, 19 Feb 1996 09:05:33 +0100 (MET)
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<tab>" 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,


Re: Wildcard inconsistencies in Windows 95 (D'Oliveiro, RISKS-17.73)

Gene Wirchenko <genew@mindlink.bc.ca>
Sat, 17 Feb 1996 21:07:13 GMT
>... 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


Re: wildcards (Armstrong, RISKS-17.76)

Jim Thompson <jthompso@netcom.com>
Tue, 20 Feb 1996 06:49:35 -0600
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 <pappinm@ayr_srv2.nth.dpi.qld.gov.au>.  PGN]


Re: Wildcards

Sean A Dunn <Sean@lilydale.demon.co.uk>
Mon, 19 Feb 96 22:47:15
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


Re: Wildcards (Stolz, RISKS-17.75)

Martin Minow <minow@apple.com>
Sat, 17 Feb 1996 19:13:26 -0800
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]


Re: Wildcards (Stolz, RISKS-17.75)

Steve_Kilbane <Steve_Kilbane@cegelecproj.co.uk>
Mon, 19 Feb 1996 09:09:54 GMT
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?

<Steve_Kilbane@cegelecproj.co.uk>


Re: Wildcards (Stolz, RISKS 17.76)

David Vu <ccdvu@cc.uq.oz.au>
Tue, 20 Feb 1996 13:07:48 +1000
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


Re: Wildcards (Stolz, RISKS-17.75)

<martin@kcbbs.gen.nz>
Sun, 18 Feb 1996 14:05:09 +1200 (NZST)
> 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


Re: Wildcards (Stolz, RISKS-17.75)

"Mario M. Butter" <mbutter@tower.clark.net>
Sat, 17 Feb 1996 12:10:12 -0500 (EST)
> 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]


Re: Wildcards (Wei-Yuen Tan, RISKS-17.75)

"Mario M. Butter" <mbutter@tower.clark.net>
Sat, 17 Feb 1996 09:29:02 -0500 (EST)
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

Please report problems with the web pages to the maintainer

x
Top