The RISKS Digest
Volume 17 Issue 79

Friday, 23rd 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…


Deep Blue - Deep Trouble
Erik Hollnagel
Dangerous C Syntax
Alasdair Rawsthorne
A future risk pays an early visit...
David Lesher
Another early year-2000 problem
Bill via Jim Sims
Netscape Navigator 2.0 exposes user's browsing history
John Robert LoVerso
Re: Java security
Marianne Mueller
For A Good Time, Type !!
Dave Tarabar
Risks of Contributing to Risks
Tom Comeau
Security of NASA command workstations
Kevin Maguire
Hidden information in files
John Gilliver
Re: Filenames (Was: Re: Wildcards)
Re: Wildcards on Mac
Li Gong
Re: Wildcards: IBM Windows ftp
John Haseler
Re: Wildcards: dos is consistent, unix isn't
Morten Welinder
Risk of any special character
Info on RISKS (comp.risks)

Deep Blue - Deep Trouble

Erik Hollnagel <>
Thu, 22 Feb 1996 08:34:06 +0100
In the latest battle between man and machine, the ACM Chess Challenge
between Garry Kasparov and Deep Blue, which took place in Philadelphia,
10-17 Feb 1996, the machine apparently ran into some unexpected problems.
Many of these were due to improper handling of the input and output, rather
than to the software itself. In the 22nd move of game four, the following
happened. The description is taken from the transcript, which can be found
on; since this is a
stenographic record, there may be some technical inaccuracies, but the
essentials are correct.

"DR. FENG: I went back and Garry is thinking I should wait there until I
finish the moves. The monitor that we are using is an energy saving monitor
so it went blank. So I went back and I am typing the move, A3 and somehow
the A did not get recognised, it recognised it as 3. And it was a command to
process number 3 and then I type F3 and the machine say I see a repetition
and then say there is a beep. And it stopped beating [beeping?] after that.
And then I check with the guy in the back room. They are saying that could
cause the program harm and I checked with Valvo and we restart the program.
Mr. Seirawan: So they had to restart the program and get it back up to
speed. How much time did that cost the computer on its clock?
DR. FENG: About ten minutes. And those are lost.
Mr. Seirawan: Just to be clear, stay with us please, ten minutes to reboot
everything and then ten minutes of lost thought time, so DEEP BLUE got hit
with a 20 minute --
DR. FENG: It would have played the same any way.
Mr. Seirawan: It got hit with a 20 minute penalty, it seems to me."

>From the risk perspective, the situation is that we have a highly developed
and very sophisticated parallel computer which is supposed to represent the
state of the art, at least in chess computing. But apparently all the
efforts have been lavished on the chess playing part and none on the
interface or input checking. Checking the syntactical correctness of the
input should be elementary, even - or particularly - in complex software
systems. Woe to the student who forgets that! But what would have happened
if the computer had not been playing chess, but been applied to share
trading, controlling a train signalling system, a satellite, a nuclear power
plant or something else where the consequences had been more severe for a
third party?

Erik Hollnagel, Ph.D., Principal Advisor, OECD Halden Reactor Project
P. O. Box 173, N-1751 Halden, Norway  +47.6918.3100

   [In a language in which dairy is pronounced daily, I suppose
   this might be Deep Yogurt — as they say in California.  PGN]

Dangerous C Syntax

Alasdair Rawsthorne <>
Fri, 23 Feb 96 13:48:41 GMT
In Continental Europe, the comma is often used where anglo-saxons
would use a decimal point.

A continental student has just asked for help with a programming
problem - the following code loops infinitely:

  while (fabs(some expr) > 0,001) {

Is this equivalent to the Fortran DO10I = 1.10 bug?

I'm just surprised not to have seen this before...


A future risk pays an early visit...

David Lesher <>
Thu, 22 Feb 1996 13:53:33 -0500 (EST)
Friends running Chameleon under Windoze recently started being unable to use
mail. Every attempt to resulted in an immediate GPF. But ftp, telnet,
Netscape, etc., all worked.

Frantic re-installs of any & everything had NO effect at all.  Chameleon
Tech support was totally baffled.

Further, reading mail with OTHER programs ALSO resulted in crashes. This
included replacing Chameleon with Eudora, Netscrape, etc.

Yet each bombed in its own module.

Four weeks into this, he spotted the non-obvious cause....

The system date had jumped to 2069 & it was the date-sorting that was

I'm beginning to seriously consider that advice [Dyson?] to withdraw
ALL your money on 30 Dec 1999 & keep it cash for a day or two....

Another early year-2000 problem

Jim Sims <>
Wed, 21 Feb 1996 13:53:04 -0500
[Forwarded] At 02:30 PM 2/19/96 PST, Bill L. wrote:
  There are fewer than 999 working days left until the year 2000. I know this
  because one day several million dollars' worth of orders `disapeared' from
  our manufacturing system. The problem was that we displayed only orders due
  within 999 working days, which happened to [reach] the first working day in
  the year 2000. The program basically displayed all orders with a date less
  than 1-2-00, of which there were none.
  How did we fix it you ask?
  Why, we changed the program to go only 500 working days into the future.

    [Lightly edited by PGN]

Netscape Navigator 2.0 exposes user's browsing history

John Robert LoVerso <>
Fri, 23 Feb 96 10:03:49 -0500
While riding home this past Wednesday (on my accident free commuter-rail
line), I came up with an approach to utilize the JavaScript "feature" of
Netscape 2.0 to track a user's browsing actions.  The tracking happens in
real time with the user's browser dutifully sending results back to a remote
server, starting from the time the user visits a page with the devious
JavaScript embedded in it.  It can thus sniff any passwords or keys the user
might use in a URL.

My example version runs in a browser window that the user can see.  I'm only
demonstrating the vulnerability.  Practically, the window can be made so
small as to be invisible to the casual user.  It also helps that a user
isn't even informed when the HTML page they just loaded has some JavaScript
code within it.

Think about Netscape's new JavaScript-laden home page.  The default action
on startup of Netscape 2.0 is to go to that page.  It could easily start off
tracking your browsing actions.  With the new on-line frontier being driven
by advertising, the value of such a log is immense.  Of course, if Netscape
really wanted to do something like this, they could embed all sorts of
things directly in their browser.  Naturally they don't, but this is
something that people often clamor about (e.g., the recent Microsoft Word
and the never ending AOL controversies).

As it stands, with Netscape 2.0 you cannot disable JavaScript.  You can
disable Java.  This is an interesting choice on their part, since at least
there has been a significant effort on the part of many people to justify
Java's claim of security and safeness.  Thousands of people have pored over
the code and specifications.

But, JavaScript and Java are totally different things.  They share common
names and syntax, but they don't share implementations.  One is a byte
compiled language executing in a restrictive state machine, the other is an
interpreted scripting languages with vastly different properties.  Compared
with the thousands of people have looked at the source to Java, no one has
seen JavaScript.  Its specifications are defined by the implementation,
which to date is solely Netscape 2.0.  We're told it is "Secure. Cannot
write to hard disk", which is how Java is also described.  Is there enough
commonality for such a comparison?  It is hard to determine that a program
is safe or secure after studying it.  It is impossible without.

My particular history tracker is the third (or fourth?) way to steal private
data from a user via JavaScript.  It stands out as the first one that does
it in real time, reporting history as the user is browsing.  In an
interesting bit of irony, as I was writing the code to exploit this hole, a
news article from someone at Netscape appeared noting how they has fixed 2.0
during the "beta-test" period to avoid the latest of the history stealing

As it stands, JavaScript adds a viral element to HTML.  I'm not sure why
Netscape doesn't ship JavaScript disabled by default or why they don't alarm
the user before it starts to execute, or opens up new windows.

Finally, it is interesting to note that the Netscape Navigator already has
the building blocks to block the execution of any JavaScript (or Java) code
that doesn't come digitally signed from some trusted source.  This would
help provide a real safeguard against the types of attack downloaded code
opens up.

My JavaScript examples are at

John Robert LoVerso  OSF Research Institute

  Added note:
    Did you ever try to teach someone the importance of keeping
    their ATM PIN secret, only to find that they never lock the
    doors to their house?
    A non-empty subset of the hosts who have visited my JavaScript
    "tracker" page run an X server with no access control enabled.

Re: Java security (Dean, RISKS-17.77)

Marianne Mueller <Marianne.Mueller@Eng.Sun.COM>
Wed, 21 Feb 1996 20:40:10 -0800
This message is a response to the DNS spoofing attack described in Drew
Dean's IEEE Security and Privacy paper, referred to by Drew Dean in his
RISKS-17.77 posting as being in .


A bit of background on DNS: (apologies for the oversimplification)

DNS is the internet "Domain Name Service".  It provides the mapping between
computer names and computer addresses.  For example, the name has the 3 IP addresses,,, and  Probably, each IP address eventually is mapped onto a
different computer, although multiple IP addresses could also map onto a
single computer.  The reason for many-to-many name-to-address mappings is
that it enables system administrators to balance the network load on their
machines.  The name is probably accessed hundreds of
thousands of times every day by people all over the network, so it makes
sense for that one name to be served by multiple machines with multiple IP

Let's use the term "DNS spoofing" to mean that a computer on the
internet has been able to advertise a false IP address for itself.
DNS spoofing isn't directly related to Java, but might be used as part
of a Java attack applet.


The attack scenario is like so.

1) The machine advertises two IP addresses for
itself, the real IP address for that machine (say and a fake
IP address for that machine (say  The fake IP address is
actually the address of, which is the computer the attack
applet wants to try to connect to, later on.

2) Someone using a Java-powered browser loads an applet from  Now, applets are allowed to make network connections
only to the machine they came from, which in this case is  However, this attack applet tries to open a
connection to the computer named "".

3) The applet security manager does a DNS lookup on the name, and checks if its IP address is in the pool of IP
addresses that this applet is allowed to connect to.  It gets the
address  It turns out that this is one of the two addresses
associated with, and so the connection is allowed.
The connection should not be allowed.

Why is this attack possible?

There are two reasons why this DNS Spoofing attack works:

    1)  It's relatively easy for someone to advertise false IP
        addresses.   That is, it's relatively easy for someone
        to run their own domain name resolver.

    2) The applet security manager allows an applet to connect
       to any of the IP addresses associated with the name
       of the computer that it came from.

What's the fix?

The right solution for this problem is to make the Domain Name Service
more secure.  It shouldn't be so easy for anyone to advertise false
names or false addresses.

A fix for the applet security manager is to be more strict about deciding
which computers an applet is allowed to connect to.  The Java system needs
to take note of the actual IP address that the applet truly came from
(getting that numerical address from the applet's packets, as the applet is
being loaded), and thereafter only allow the applet to connect to that exact
same numerical address.  Additionally, the Java system could be even
stricter than that, by declaring that an applet can only connect to the same
port number that it came from, in addition to only being allowed to connect
to the same IP address that it came from.

What's the bottom line for me today?

An applet on its own cannot carry out this attack.  It would have to be
working in conjunction with a hacked DNS server owned and ascribed to some

Also, the attack applet would have to know the name and IP address of
machines inside a corporate firewall, in order to try to establish a
connection to machines behind the firewall.

Sun will be distributing a patch to the applet security manager to implement
the more rigorous checking described above.  That fix will be available
within a few days, and it will be distributed in source code and in bytecode

For A Good Time, Type !!

Dave Tarabar <>
Thu, 22 Feb 1996 08:47:41 -0500
*The Boston Globe*, 22 Feb 1996, reports that Socks the cat appears to be
running an objectionable web site at the White House.

Surfwatch is a commercial product that attempts to protect the user from
objectionable content available on the Internet.  Apparently it works by
searching for `hot' words. On the White House Web pages, Socks the cat has a
virtual tour of the White House and one stop on the tour contains the word
`couples'.  This got that page on the tour blocked by Surfwatch.

Responsible adults may judge for themselves at

Dave Tarabar, SystemSoft Corp., 2 Vision Drive, Natick, MA 01760

  [Other filters have tripped on this one, but somehow have not get made
  it into RISKS.  The *San Francisco Chronicle* a while back showed
  a web page with four photos — of the Pres and VP and their wives --
  that was censored by one of the service providers because of the
  offensive word "couples".  Will RISKS now be so censored because of
  this item?  Stay tooned, he said, comically.  PGN]

Risks of Contributing to Risks

"Tom Comeau @ Space Telescope Science Institute" <>
Fri, 23 Feb 1996 13:00:53 EST
Recently (RISKS-17.70, item 1) I contributed a short article on the risks
associated with an automated train-control system.  A few weeks prior to
that I had contributed a joke about French nuclear testing to
rec.humor.funny.  I'm also subscribed to the SCRNWRIT mailing list, and
regularly make contributions.

Brian Lynch reminded us (in RISKS-17.78, item 3) of some of the Risks of
not thinking before submitting, but I have been rather nastily reminded
of another.  After both news postings, I received several rather nasty
e-mail messages questioning my intelligence, heritage, and character.

One response to the RISKS article suggested I was an idiot for not
recognizing that only a moron would leave a speeding train under automatic
control.  (Which ignores several decades of psychological research on the
willingness of people to submit to authority figures, such as the supervisor
who refused permission to switch to manual.)

The responses to the joke were even nastier.  One writer suggested that
people like me were "threatening the safety of the Free World" with such
comments.  (He probably could not know that I approve of the testing regime
as important to the French weapons safety program.)

While this hasn't risen to the level of threatening phone calls
reported in RISKS-17.75, item 5, my office phone number was (until
recently) included in my .sig files, so it is certainly possible that
things could get that out of hand.

I have made contributions in print media (for example, Letters to the
Editors of both Newsweek and Playboy) but those have included only general
information, such as a name and city.  A determined attacker could still
find me, but the ease of replying to electronic postings seems to encourage
immediate attacks.  Playboy now prints the e-mail addresses of people who
send electronic Letters to the Editor.  If I send Playboy anything in the
future, I will be sure to send it on paper.

I supposed I could stop contributing electronically, or ask that any
contributions be anonymous.  However, among the few flames were some
thoughtful comments (and one kind correction) that I am loathe to forgo.

The main Risks seem to be the ease and immediacy of electronic attacks, and
the ability (using DejaNews, etc) of the disgruntled to gather additional
details about a person with whom they disagree.  This is not really news to
veterans of Usenet newsgroups, but people contributing to any electronic
forum need to be much more prepared for "flamage" than someone writing to a

Tom Comeau <> Computer Scientist,
Space Telescope Science Institute

Security of NASA command workstations

Kevin Maguire <>
22 Feb 1996 22:20:15 GMT
Re: Lack of Common Sense is Biggest Risk Of All (Gunderson, RISKS-17.73)

At least at JPL, there's an enormous difference between the security
procedures applied to the personal workstations and the flight workstations.

I won't go into any details, to avoid giving anyone hints, but when a new
procedure was put into place for access to the secure machines, my first
attempt to log into the secure machines failed due to a misundertannding
about the procedure.  I got a phone call from the SAs within 6 hours,
checking to make sure the series of failed attempts was indeed me.

Kevin Maguire

Hidden information in files (was WORD risks)

John Gilliver <>
Fri, 23 Feb 1996 11:20:18 +0000 (GMT)
The problem of files containing other information than that shown in the
application which generated them certainly predates Word; I have seen such
information by looking (with Xtree or similar) at various files. In
particular, newsgroup postings often contain them, presumably due to people
`including' files generated by their favourite WP without realizing that
this would happen.

Surely the problem is the original application saving more of memory than it
needs, or (if the case is that garbage is picked up from the disc)
incorrectly writing the file size to the directory when it does a disc write,
so that subsequent reads read more than necessary? The extra information is
certainly not needed to reconstitute the file.

J. P. Gilliver, GEC-Marconi Research Centre, GEC-Marconi Ltd, GREAT BADDOW,
Essex, CM2 8HN, UK.   +44 1245 473331 x 2133

Re: Filenames (Was: Re: Wildcards)

Thu, 22 Feb 96 08:43:08
If I may step back a bit from the wildcards arcana, perhaps the real risk
is the notion that files are anything other than their entire contents.

With MacOS, DOS/Windows and UNIX we (the humans) use filenames to identify
files, while they (the computers) use serial numbers and the file contents
to perform the same task. We choose to give our files names to indicate
to us what the files contain. Some of us choose to give our files special
names to indicate to the computer what the file contains.

Now we've had two risks associated with this behaviour mentioned close
together. One day it's Microsoft's Word for Windows and its virus, the next
it's - oh, look - Microsoft's Windows 95 and its wildcard inconsistencies.
(Interesting to note that the only complaint about UNIX's wildcarding was
from someone who though ls was equivalent to dir - is this just because
UNIX users are better-educated, or because UNIX is more consistent? Either
way, the untrained users are the ones left with the poor tools.)

But I want to consider the claim that the problem with OSes that offer a
command-line is that they "require an equivalent amount of understanding of
the inner workings of the operating system," which "may be unreasonable in
an era of pervasive personal computing."

What alternative can we go out and buy?

Does using icons in preference to text help? The visual wildcarding is
performed in one (terribly inconsistent) place - my brain. And I see files
that look similar, and get the wrong one. Because if they *look* the same,
then they obviously *are* the same.

Does clicking rather than typing help? I can click quicker than I can type.
And I can usually select all or "lasso" a group. So I don't use wildcards as
much, and only resort to a shell when I want rid of all the files ending in
.o (lasso-ing files with similar endings is harder than those with similar
beginnings). So I'm less likely to abbreviate and make mistakes. But I make
still make mistakes. They're just different mistakes. Off-by-one errors
and accidental inclusions/exclusions of previous selections are hard to
imagine at the shell prompt.

Names are inadequate for describing a file's type, and they're even worse
when it comes to describing a file's contents. It makes no difference
whether I type a filename or click it, say it or write it (Apple do have
one great product). It's the *naming* itself that's the real problem.

Until we can ask our computers to "get rid of all the files that I'm never
going to want ever again", there'll be trouble.

But I'm not worried. I alias rm to rm -f, disable my dumpster and trust in
backups. And even with such recklessness I've only ever had to ask for two
files to be recovered.

If you don't have a good system, make sure you get good users.

- enh

Re: Wildcards on Mac (RISKS-17.78)

Li Gong <>
Wed, 21 Feb 1996 12:03:59 -0800 (PST)
Martin Minow described the virtue of Macintosh's two-stage delete process --
dragging a file's icon to the trash bin and then emptying the bin.  However,
what if I want to delete more than one file and do not want to do the drag
and drop many times over (in other words, what is the equivalent to the use
of wildcards)?

A common solution is to select many files at one time (by holding down the
Shift key and clicking on icons) and then moving them all in one go.  Risks?
Once I was trying to move a fair number of files (to another directory, not
to the trash bin).  After I had selected a few icons, I accidentally hit the
space bar.  In a flash all those selected files disappeared, straight to the
void and not to a middle-stage trash bin.  It is amusing that the largest
key on a keyboard is assigned this short-cut functionality.

Li Gong, SRI International,

Re: Wildcards: IBM Windows ftp

John Haseler <>
Thu, 22 Feb 96 23:52 GMT
I found an interesting variant on this theme.  Using the IBM Windows package
for FTP, I wanted to access a mainframe I never use and get a file which was
supposed to have been put in my directory.  The FTP package is nicely
designed, with windows showing local and remote, and you select files either
by typing a name or clicking, then hit on an arrow to transfer them.  I was
not sure what to expect nor what the file name might be, so I typed in "*"
in the remote window and clicked on the arrow (I may also have given a
confirming response). The PC disc seemed very busy and odd messages were
flashing across the window: when I aborted, nearly every file in the current
directory on the PC had been deleted.

I guess the (cautious) IBM approach to transfer is this: Does the file
already exist on the TO machine and directory? If so, remove it: if this
works, transfer from the FROM machine.  So, to transfer "*" you first delete
"*" ... and to crown it all, in my case the file had NOT yet been copied for
me to FTP.  Result: copying all files to my machine added none and removed
all.  (It is possible that newer versions may be better behaved).

Re: Wildcards: dos is consistent, unix isn't

Morten Welinder <>
Fri, 23 Feb 1996 01:00:08 +0100
As far as the method of handling wildcards goes msdos is
consistent while unix isn't:

msdos:  wildcards handled by application.
unix:   wildcards sometimes handled by shell ("ls -l *") and
    sometimes by application ("find -name '*~' -print").
    (And weird examples could mix those.)

Due to better and more available libraries Unix usually comes out ahead, but
still we have inconsistencies with respect to (say) file names starting with
a dot.

Morten Welinder

Risk of any special character

Thu, 22 Feb 1996 13:58:34 +0100
Concerning the discussion about inconsistent expansion of wildcards I can't
help submitting one of my favorite mistakes in assuming program behavior.

I was using "mail -f toobig" on a unix system in order to distribute emails
from folder "toobig" to different folders, one of them named "important".
Now, if you save *incoming mail* to a folder it gets deleted automatically
(mv'ed), if you do that from a different folder it stays there (cp'ed). I'm
sure there are reasons for that.

Now at a certain point I considered myself very smart and typed
"s important;d" assuming that was one command for saving and one
for deleting to be executed one after the other. The message
"Saved to 'important;d' [New file]" quickly informed me about my
mistake, I repeated the action using two commands as usual, made
a mental note to delete the junk file and kept going.

Then the work was done, I left the "mail" program, decided to clean up and
go home. Thus, I issued "rm important;d". Although it was not funny I had to
laugh when I was told "d: command not found".

Worst of all, I don't believe that this sort of risk can be resolved unless
one wants to use a formal language for issuing commands, which I don't. And
do not tell me that clicking subsubwindows makes the situation any better.


Please report problems with the web pages to the maintainer