The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 17 Issue 76

Saturday 17 February 1996


o Train collision - Maryland
David Lesher
o Risks of using Microsoft Word
Thomas Gebe
o Win95 screen savers - Security Bug?
Matthew Delaney
o Re: Virtual Reality dangers
Paul Zrepachol
Centre for Computing and Social Responsibility
o CDA interpretation: transmitting vs receiving
Stanton McCandlish
o Deleting Files in Win95
Matt Armstrong
o Wildcard inconsistencies in Windows 95
Lawrence D'Oliveiro
o Re: Wildcards
Michael Smith
Peter Curran
Matt Welsh
o Re: RISKS of typing credit-card numbers
Nathaniel Borenstein
Olin Sibert
o Info on RISKS (comp.risks)

Train collision - Maryland

David Lesher <>
Sat, 17 Feb 1996 17:21:55 -0500 (EST)

I'm only a few miles from yesterday's wreck.  The known facts to date:

The Amtrak was ""passing"" a stopped freight by crossing over to the
other track, then crossing back. For whatever reason, the inbound
MARC had NOT stopped [short of the 2nd crossover], & the two
passenger trains collided head-on.

This is EXACTLY the worst case accident scenario railroad signal
systems & procedures have been designed to prevent; designed so for
many decades. [When WAS the first RR block signal installed?]

Yet it happened anyhow.....

The RISK? Whether despite, or because, or coincidental to CSX's
centralized dispatch & track management system; or the weather, or
human error; sometimes, alas, old Risks cannot be eliminated, only
constrained one day at a time.....

Risks of using Microsoft Word

Thomas Gebe <>
Fri, 16 Feb 1996 23:01:29 GMT

Recently I was asked to type up a resume for a friend and provide both a
hard copy and a copy on disk.  I typed it up using Microsoft Word.

Before I gave her the final copy, I wanted to double-check one piece of
information.  Since I didn't want to wait forever while Word came up, I sent
it to a simple text editor.  I was shocked to find that buried among the
text and code were several URLs that I had visited while cruising the Web!
One of the addresses included my username and password for a foreign
electronic paper that I subscribe to, and one, to my embarrassment, was  <Blush> None of them showed up when viewed with
Word, and if I hadn't checked it with the text editor, I wouldn't have known
they were there.  Fortunately, it was no big deal, but the security and
privacy risks are obvious.

I have no clue how they ended up embedded in my Word document.  I don't use
Microsoft Assistant for Word (or whatever it's called).  The only other
thing I can think of is that I was cruising the Web at the same time I had
the document open and somehow they ended up there.  Nonetheless, you can bet
I will be checking all my Word documents with a text editor before sending
them out to anyone!

Win95 screen savers - Security Bug?

Matthew Delaney N2MDB <>
Sat, 17 Feb 1996 11:38:26 -0500 (EST)

I've noticed that if my DOS prompt icon in Windows '95 is "depressed" on the
taskbar, but not in the foreground, and I have screen savers disabled in its
properties, the screen saver will not come up. This could be a security
risk: If I have my screen saver password protected, and the desktop is
showing, I would assume (and did assume) that my screen saver will come up.
I wonder if this is a "feature" in that as long as the item is selected on
the taskbar the screen saver would not come up, even though it is not
fullscreen, or if this is a bug.  My advice: Make sure the program on the
taskbar is a windows app. or nothing at all is "depressed".

Matthew Delaney  N2MDB   ax.25:
Finger for PGP key

Re: Virtual Reality dangers (Cohen, RISKS-17.73)

Sun, 18 Feb 96 00:27:01 +800

> ... Using his finely tuned, VR trained reflexes, he immediately
> crashes into the other car.  Is this risk plausible?

Not only plausible, but IMHO, quite real. See the extensive work on flight
simulators, etc., for the details and risks.

Can I draw RISKS readers attention to 'New Scientist' 27Jan pp 34-37,
"Virtually Real, Really Sick." This give some very sobering food
for thought on VR systems.



Centre for Computing and Social Responsibility <>
Fri, 16 Feb 1996 15:46:58 +0000 (GMT)

           The Third International Conference on
          Ethical Issues of Information Technology

Hosted by Facultad de Informatica, Universidad Pontificia de Salamanca en
Madrid, in association with Centre for Computing and Social Responsibility,
De Montfort University, UK and Research Center on Computing and Society,
Southern Connecticut State University, USA

             Preliminary Notice and Call for Papers
Two international conferences have been held which address the social and
ethical issues surrounding the world of computing. The first was in the USA
at Southern Connecticut State University (NCCV91) and the second
(ETHICOMP95) was at De Montfort University in the UK.  Both conferences have
been recognised as milestone events.  In order to sustain momentum and
advance resulting research, a third conference ETHICOMP96 is to be held in
Madrid. The intention is to bring together international scholars to
consider current and future developments of IT and resulting social and
ethical issues. Madrid is an ideal location for this conference, being a
major European capital with a high cultural, academic and commercial

The overall theme of ETHICOMP96 will be the value of IT to society and the
likely impacts upon society's values. The intention is to include papers
which provide practical guidance on socially and ethically sensitive
applications of IT -- the social benefits and drawbacks of using IT. In
parallel to this will be the presentation of case studies which raise or
illustrate significant ethical problems of IT usage (1) in the workplace,
(2) in education, (3) at home and (4) in leisure. Papers and case studies
are invited from relevant disciplines such as philosophy, computer science,
information systems, law, social sciences, business and government.  Papers
and case studies with a multi-disciplinary perspective are particularly

See full details in English or Spanish by accessing

For further information contact:

Centre for Computing and Social Responsibility
School of Computing Sciences
De Montfort University
The Gateway

Telephone +44 116 257 7475
Fax +44 116 254 1891

CDA interpretation: transmitting vs receiving (Ohlendorf, RISKS-17.75)

Stanton McCandlish <>
Fri, 16 Feb 1996 19:04:16 -0800 (PST)

>... This is receiving, not transmitting.

For the purposes of the law, "transmission" means "sending of data", more or
less.  Your http server is "transmitting" the info to the visitor's browser.

>I know this is semantics at this point;

Beware the difference between common-parlance semantic differences and legal
terms-of-art semantic differences.  In common parlance, "obscenity" isn't as
bas as "indecency" to many people, since a "swear-word" is an "obscenity".
Legally, it's not an obscenity, but an indecency, and obscenity is more
stringently proscribed than indecency.  The understandable lack of knowledge
of legal terms of art (don't feel bad - a lot of lawyers don't know the
difference between obscenity and indecency) is the primary means by which
the fundamentalist groups behind the CDA have managed to increase supposed
public support of it. They perpetually uses the terms interchangeably, and
then suggest that the CDA will prevent the "exploitation of children" ( -
Cathy Cleaver debating Jerry Berman on tv the other day).

To state it as a RISK:  It is easy for fundamentalist groups to gain
more acceptance of the idea of censoring online communications, by combining
loaded terms that imply something else ("exploitation of children" is
very emotional a phrase, and implies child pornography, rape and abuse -
subjects not in any way relevant to the CDA) with confused terms that
most of the public didn't have a legal understanding of even before the
confusion was introduced (e.g. "indecency", "obscenity" and
"pornography", which is legally a synonym of "obscenity" as are "harmful
to minors" and, as far as we can tell, "patently offensive".)

Stanton McCandlish  Electronic Frontier Foundation  Online Activist

Deleting Files in Win95

"Matt Armstrong" <>
Sat, 17 Feb 96 17:17:21 UT

After I saw D'Oliveiro's notes (see below) on the "?" wildcard and its use
within Win95, I did some testing with Visual Basic 3.0, Visual Basic 4.0,
Access 2.0, and Access 7.0 (aka Access 95). The KILL statement (used to
delete a disk file) is implemented in three different ways!

Start with 6 files in a directory (mine was C:\TEMP): TEST9.TXT,

VB 4.0 and Access 7.0 using KILL "C:\TEMP\TEST9?.TXT" will delete two files:
VB 3.0 using KILL "C:\TEMP\TEST9?.TXT" will delete three
files: TEST91.TXT, TEST92.TXT, and TEST9.TXT.
Access 2.0 using KILL "C:\TEMP\TEST9?.TXT" will delete two files: TEST.TXT,
and TEST9.TXT. (I don't understand this one!)

I could not find any note of the differences in the help files or the
Developer Network CD (Jan 96). So it is left up to your user to find out!

Isn't this a RISK where deleting a file from code has a different effect
when you switch versions? It really demonstrates that you can't trust
converted code, you still have to test each and every feature.

Wildcard inconsistencies in Windows 95

"Lawrence D'Oliveiro" <>
Wed, 14 Feb 1996 09:39:05 +1300

I just read something disturbing in PC Magazine, which I have verified is
true. 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".

Suppose you have a directory with two files in it, one named XX and one
named XXX. The command "DIR XX?" will only show the second file, but "DEL
XX?"  will delete both files!

One dependable rule in every computer system I have ever used prior to this,
is that a wildcard specification will always expand to the same set of
filenames, regardless of what command you use it in. Wind95 not only breaks
this rule, it breaks it in the worst way: the "delete" command, given the
same wildcard specification, will delete a larger set of files than the less
harmful "directory" command will display! This means you can no longer use
the technique of checking a wildcard specification with DIR to make sure it
will only affect the right files, before letting it loose with DEL.

Lawrence D'Oliveiro, Computer Services Dept, University of Waikato
Hamilton, New Zealand    +64-7-856-2889

Re: Wildcards (RISKS-17.74)

Michael Smith <>
Sat, 17 Feb 1996 22:00:39 +1100 (EDST)

An interesting technicality in the discussion of inconsistent wildcard
expansion in Windows 95.

In MS-DOS the DIR and DEL commands are not programs, the are "internal
commands" which are processed by the command interpreter (COMMAND.COM).  I
don't have a copy of Windows 95 handy, but I would assume that this is still
the case.

Thus we do not have a case of different programs interpreting wildcards
differently, but the same program (the command interpreter) interpreting
them differently in a different context.

Michael Smith                             
Emmenjay Consulting

Re: Wildcard inconsistencies in Windows 95

Peter Curran <>
Sat, 17 Feb 1996 16:10:56 GMT

A couple of people have pointed out a typo in my posting on this subject -
the limit on command-line length on the old UNIX system I used was 512
bytes, not 51.

Now there's a RISK - keyboards that won't type what you mean.

Peter Curran                     

Re: Wildcards (Stolz, RISKS-17.75)

Matt Welsh <mdw@CS.Cornell.EDU>
Fri, 16 Feb 1996 22:04:45 EST

In 17.75, Otto Stolz points out that the UNIX 'ls' command will list
more files than the 'rm' command would remove if (shell-globbed) wildcards
are used:
        ls x*
lists all files, directories, _and the contents_ of directories beginning
with the character 'x', while
        rm x*
will remove only files beginning with 'x' (not directories).

There is an important issue at work here: That universal wildcard expansion
(as is done under the UNIX shell) does not equivale universal argument
interpretation. 'ls' and 'rm' interpret their arguments in very different
ways; 'rm' won't delete directories, and 'ls' lists the contents of
directories. (ls -d could be used to circumvent the second of these).

While this may be obvious, I think it's important to point out that
pre-globbed wildcards simply produce a list of words as command-line
arguments; this in no way implies that the program using those arguments
should interpret them in a particular way.

This can be exploited in both good and bad ways; for example, if a directory
were to contain a file named '-i', then 'rm *' in that directory would
expand to 'rm -i ....' (assuming '-i' is the first expanded filename in
the wildcard). The -i switch to rm forces interactive mode where the user
must answer 'y' or 'n' to delete each file. I know some people use this to
'protect' certain directories from accidental 'rm *'.

However, one could also create a file named '-rf'... This exercise is left
to the reader.

Don't be fooled: UNIX syntax is in no way based on hard rules---conventions
are the dominating factor. Needless to say there's also no guarantee that
a particular shell expands the '*' and '?' wildcards as one would normally
expect. The various tradeoffs here have to do with where the conventions
are embodied: In Win32 systems, they are within the application itself;
under UNIX, they are generally within the shell. Which would you rather
have---'invisible' (and unalterable) semantics within each particular
application or 'treatable' semantics enforced by your shell (and applied to
all applications)?

The RISK here has to do with software conventions and non-obvious behavior
of (apparently) mundane software. Conventions such as these permeate
UNIX, and I know more than one UNIX neophyte who has been bitten by them.

M. Welsh,

Re: RISKS of typing credit-card numbers (Sibert, RISKS-17.72)

Nathaniel Borenstein <>
Sat, 17 Feb 1996 10:20:14 -0500 (EST)

I'd like to make a few clarifications about the FV credit card attack
demonstration program, as there have been a few misunderstandings in the
way it was described on RISKS.  At the moderator's request, I'm keeping
this as short as possible; full details are at, or by personal mail.

-- Our "overstated" claims were overstated by those who described them.
We do not claim that there's no possible technical defenses; in fact, we
enumerate several such defenses, and also outline four broad classes of
commerce systems that do not have this flaw, only one of which is our
own.  I do apologize for some probably-misleading wording, however.

-- It is true that the threat goes beyond commerce mechanisms.  If word
processor vendors were telling the world "everyone should type credit
card numbers into word processors" we would probably have focused on
word processors, too.

-- Antiviral and other prophylactic software can only protect against
the LAST attack of this kind, not the next one.  The infection vector
can be a socially-engineered Trojan Horse, and once installed the
program does nothing that categorically distinguishes it from a screen
saver or keyboard accelerator.

-- The complexity of our attack has been overstated.  Credit card
numbers can be recognized with about 8 lines of C code.  My favorite
approach to the traceless dissemination of the data can be done in about
20 lines of C code.  The hardest part is the installation and the actual
keystroke interception!  The DLL for our current Windows implementation
is under 16K.

-- It is true that the most likely detection would be by the sheer
volume of traffic on the back-channel, but there are also simple
traffic-gating techniques.  And users should never get errors back from
a well-implemented distribution channel.

-- Address verification isn't the answer.  It can be very effective in
preventing a certain class of *uses* of stolen credit card numbers, but
there are many other ways to use such numbers, especially for

-- Current credit card fraud detection is inadequate.  Nearly all of the
traditional fraud detection mechanisms are based on pattern analysis,
and the criminals typically get nabbed after repeated uses of the same
stolen card number.  This is not very helpful against an attack that
yielded enough card numbers to treat them as one-time tokens.

-- My most serious disagreement with Olin Sibert is on the question of
the easy infiltration of home machines.  Up to now, there has been no
motivation for serious criminals (organized crime, terrorists) to build
malicious computer programs.  Organized crime and terrorist groups have
both the means and, in a future of Internet commerce, the motivation to
mount such an attack.  A sufficiently unsophisticated user can easily be
tricked into downloading and running a malicious program.  The essence
of the FV attack on credit card numbers is statistical; we don't need to
infect the machines of the most sophisticated users, as long as we can
infect a lot of unsophisticated users' machines.

***The true and neglected underlying risk is that of system security
being compromised by unsophisticated end-users.  Today, we live in an
Internet where people consider "cut and paste" a technical term, and
where users complain of getting so lost in a web site that they have no
way of escape other than rebooting their machine.  (Yes, these are both
based on real customer service incidents at First Virtual.)  The
permanent insecurity of the consumer platform is an under-appreciated
reality of 1996.  The bottom line:  a commerce mechanism that presumes
that the consumer's machine has not been compromised is a commerce
mechanism that will be easily defeated on the bulk of consumers'

I hope these clarifications shed some light on what FV is and is not
claiming about the risks of credit cards on the Internet.  I think
there's a very serious set of risks here, and I hope that those risks
haven't been overshadowed, in the technical community, by the confusion
that comes from trying to alert the wider population to the fact that
such risks exist.  If I'm right, then the first symptom the banks are
going to have of such an attack will be an increase in the overall rate
of credit card fraud, with NO evidence linking this phenomenon back to
the Internet.  I think that's a huge potential risk.

Anyone interested in more details on the flaw FV has been demonstrating
can find more information at  -- Nathaniel

Nathaniel Borenstein <> Chief Scientist, First Virtual Holdings
FAQ & PGP key:

Re: RISKS of typing credit-card numbers (Borenstein, RISKS-17.76)

Olin Sibert <>
Sat, 17 Feb 96 14:23:34 EST

I think the response above from First Virtual is sufficiently laden with
concessions to show the debate for what it really is: a difference of
opinion over the importance of various unmeasurable factors, such as:

 - The likely competence (or lack thereof) of potential attackers;

 - The difficulty of translating laboratory prototype software into a
   secret, widely-distributed, error-free, mass-market consumer product;

 - The ease with which stolen credit card numbers can be turned into
   value for an attacker (and risks posed by such activity);

 - The availability and effectiveness of all types of counter-measures
   (the dismissal of prophylactic software is arguably unimaginative);

 - The effectiveness of existing fraud-detection measures;
    ... and so forth.

If we make assumptions at one end of the scale, society could collapse
in a fortnight.  Under other assumptions, nothing much happens.  Much
depends on those assumptions--and the real RISK is that a one-sided
presentation can alarm without educating.

Please report problems with the web pages to the maintainer