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 18 Issue 79

Tues 28 January 1997

Contents

o Spamming Risks and Solutions
Simson L. Garfinkel
o Risks of floor repair
Paul Bissex
o Computer Glitch Gives Investors Instant Loss of Balance at Schwab
Norm deCarteret
o Microsoft Office 97 Steals My Initials, MSOF
Michael S.O. Franz
o Cosmic radiation can cause computer memory loss
Martin Minow
o Re: Shetland Times copyright suit
Prabhakar Ragde
John Pelan
o Re: Macintoshes and Y2K
Bear Giles
Jonathan Stott
o Y2K on non-Unix/Microsoft systems
Steve McKinty
o Re: Y2036, Y2038, and the superiority of UNIX
Frederick G.M. Roeber
o URL filtering, Re: ad.doubleclick.net
Caveh Frank Jalali
o Guilty by confusion? Domain names and IP addresses of net.abusers
Lars Wirzenius
o Adios ads.doubleclick.net
John Hascall
o Side benefit of proxies re cookies
Mark Seecof
o Risks of communicating with the wrong person
James W. Birdsall
o E-Mail Addressing Problems
Todd Burgess
o Verifying Mail Addresses
David Fetrow
o AOL software flaw
JMFBAH
o 4th ACM Conference on Computer and Communications Security
Mike Reiter
o Info on RISKS (comp.risks)

Spamming Risks and Solutions

"Simson L. Garfinkel" <simsong@vineyard.net>
Mon, 20 Jan 1997 20:30:41 -0800
On Monday, 13 Jan 1997, Vineyard.NET was apparently attacked by a
spam-for-hire company.  The organization, "CV Communications," connected to
our SMTP server and started sending us advertisements for its own spamming
services.

I discovered the attack after approximately 66,000 messages were sent.  Most
of them went to subscribers of AOL and CompuServe.  I contacted the spammer,
using the phone number at the bottom of each message he was sending out, and
demanded that he stop.

Spamming is a known problem on the Internet.  I'm hopeful that
law-enforcement agencies will start seriously looking into this problem, as
I think that there is a limit to how effective technological solutions can
be.

However, there are several solutions that I have thought of.

1. Limit the number of RECV recipients permitted in each SMTP transaction.

Rather than sending out tens of thousands of messages, we were hit with a
few hundred messages that each had more than 100 recipients. We have
therefore modified our netperm-table file to limit the number of recipients
that each SMTP connection can have.

2. Disallow transiting.

Vineyard.NET's SMTP server is used both by our customers to send out
messages and by others on the Internet to send us messages. But it shouldn't
be used by others on the Internet to send messages through us to third
parties. We have therefore modified our SMTP server so that it can tell the
difference between an internal connection and an external
connection. External connections are not allowed to transit through us to
other external mail servers.

3. Reject messages that come from "suspicious" sources.

We have not implemented this yet. However, it seems reasonable to reject out
of hand any SMTP message from certain kinds of hosts. For example, you might
want to reject those from addresses that do not have a valid domain name, or
from hosts that appear to be dialup addresses.

I have written an article about this spamming incident which will appear in
my 28 Jan 1997 Packet column. You can view it at
http://www.packet.com/garfinkel on Wednesday January 29th.

I have also made my modified SMTP server available. It is located at
http://simson.vineyard.net/hw/spam2/smap.c . This is a modified version of
the Trusted Information System's SMAP server, part of their firewall
toolkit. It is my understanding that FWTK is no longer being maintained by
TIS, which is a pity.

Simson L. Garfinkel, Visiting Scholar, University of Washington,
Columnist for PACKET <http://www.packet.com/garfinkel> and The Boston Globe.


Risks of floor repair

Paul Bissex <pb@well.com>
Sat, 25 Jan 1997 13:14:16 -0800 (PST)
  Last summer, contractors at Commonwealth Edison's LaSalle nuclear
  power station were filling cracks in a concrete floor by pumping them
  full of foam grout.  What the workers didn't know, though, was that a
  tunnel ran beneath that floor, carrying water for some safety systems at
  the plant, and their grout was pouring through the cracks into the water.
  The grout partially clogged the tunnel, compromising safety at the plant
  for 10 days before Edison -- when pushed by federal inspectors -- finally
  figured out what was wrong.  [*Chicago Tribune*, 25 Jan 1997, front page]

The NRC levied a $650,000 fine for what they called a "very significant
safety problem."  Without getting into a debate about nuclear power, I think
one could point out the risk in thinking that there are any non-critical
jobs where critical systems are concerned.

Paul Bissex   pb@well.com    http://www.well.com/user/pb/tech/

  [Grout, Grout, Dammed Slot!  PGN]


'Computer Glitch Gives Investors Instant Loss of Balance at Schwab'

"Norm deCarteret (813-878-3798 (TL 438)" <nsdec@VNET.IBM.COM>
Thu, 23 Jan 97 08:06:05 EST
A program error caused Schwab's computers to omit a significant number of
mutual funds when investors used Telebroker to track holdings by phone,
leading some of them to believe themselves broke.  The problem existed from
Monday afternoon through late Tuesday evening scaring scores of investors.
Janus, Putnam and Schwab's own funds were among those omitted from net asset
calculations.

Tracey Gordon, Schwab spokeswoman: "We were making some system changes when
there was a program error."  On why the problem went on so long: 'Mutual
funds are priced once a day.  We found that it would be cleaner and simpler
to wait until the next regularly scheduled market change to update the
system'.  Cleaner and simpler for Schwab, presumably.  Gordon said investors
who made panicky trades as a result 'would be made whole' but there'd be
risks in determining both the who and the how much.

Norm deCarteret


Microsoft Office 97 Steals My Initials, MSOF

Michael Franz <franz@UCI.EDU>
Wed, 22 Jan 1997 15:56:04 -0800
My full name is Michael Steffen Oliver Franz, which makes my initials
"msof". I usually use these initials in internal correspondence, and I
have an e-mail address "msof@sprynet.com".

Now, I just installed Microsoft Office 97 on my computer.

Curiously, Office 97 automatically replaces some occurrences of "msof" by
"Microsoft Office". For example, this happens in the "initials" box in the
Word Annotations dialog. I am not yet sure how far-reaching this automatism
is, but the prospect of having my name replaced without my knowledge is
frightening. You can see this strange effect for yourself if you type "msof"
at the start of a line in Word and then wait for a short time.

Michael Steffen Oliver Franz
franz@uci.edu (university business) and msof@sprynet.com (private)


Cosmic radiation can cause computer memory loss

Martin Minow <minow@apple.com>
Fri, 24 Jan 1997 10:08:38 -0800
An article in the Swedish newspaper Svenska Dagbladet (1997 Jan 24)
currently available on their web site http://www.svd.se/ describes research
carried out by Ericsson Saab Avionics by Karin Johansson that suggests that
computers, especially those carried on high-altitude aircraft flights, may
be at risk for cosmic radiation.

Johansson and her colleagues carried out experiments on SAS transcontinental
(Atlantic) flights that measured one [bit] error per memory chip per 200
hours. The article notes that a modern personal computer may have 64 such
chips. This means that an ordinary laptop PC may expect an error every three
hours, or about twice during an atlantic flight. [Assuming you brought
enough batteries.] The problem is worsened when the flight path is over the
North Pole because the earth's magnetic field, which normally protects
against cosmic radiation, is directed such that the protection is lessened.

Karin Johansson notes that the computers used to control the aircraft itself
"are not the absolutely most modern, and consequently their electronic
circuits are not as small and sensitive." However, component manufacturers
are not interested in building electronics for such a small market as
avionics, so the aircraft manufacturers must use the electronics available
in the marketplace. To protect against error, aircraft computer designers
will use parity and error-correcting circuitry to prevent a single-bit error
from propagating into other computation.

Summerized and translated by Martin Minow, minow@apple.com


Re: Shetland Times copyright suit (Randell, RISKS-18.78)

Prabhakar Ragde <plragde@plg.uwaterloo.ca>
Fri, 24 Jan 1997 09:51:35 -0500 (EST)
The Shetland Times has obtained a preliminary injunction against the
Shetland News to prevent the News's web site from linking to Times
documents. Part of the judge's reasoning was that the advertising material
on the "front page" of the Times could thus be bypassed.

I did an AltaVista search on the phrase "Shetland Times" and came up with
lots of links into the depths of the Shetland Times site. Presumably DEC has
committed the same offense as the Shetland News, and their new European
mirror site might be vulnerable to a similar challenge.

Given the usual response to any attempts to remove "offensive" or "illegal"
material from the Net, I'm surprised that I didn't turn up dozens of
third-party links into the Shetland Times site, in defiance of the reasoning
behind the injunction.

Prabhakar Ragde, Department of Computer Science, University of Waterloo
Waterloo, Ontario CANADA N2L 3G1  (519)888-4567,x4660 plragde@plg.uwaterloo.ca

  [There were several longer messages with similar points.  PGN]


Re: Shetland Times copyright suit (Randell, RISKS-18.78)

John Pelan <johnp@am.qub.ac.uk>
Thu, 23 Jan 1997 20:18:45 +0000 (GMT)
The judgement, as I believe it should be interpreted, means that it is the
duplication of the headlines themselves which breached the copyright
law. Whether they link to the original Shetland Times articles or different
articles on the same story is irrelevant.  The judge believes that the
headlines constitute a separate work.

It think that his decision was in line with the intention and spirit of the
copyright law.

Also, I note that RISKS contributions with URLs seem to be increasingly
giving away the registered account information, namely

http://www.the-times.co.uk/news/pages/tim/97/01/21/timlawscl01001.html?10695

This contains '10695' at the end, which is what identifies the user and
now permits anyone to access The Times site in that guise. Watch out for a
change in personal preferences !

John Pelan (J.Pelan@qub.ac.uk)

  [Note, in the above the '10695' is in fact a truncation of the full set
  of digits that were in the URL that Brian had posted.  In a side message,
  Brian recommends that in the future that he/we indicate when such
  alterations are made.  PGN]


Re: Macintoshes and Y2K (Wood, RISKS-18.78)

Bear Giles <bear@indra.com>
Thu, 23 Jan 1997 19:20:43 -0700 (MST)
>Macintosh users probably have less cause for concern about the year 2000
>than any other computer users, thanks to Apple's farsighted programmers.

This gem illustrates just how nasty the Y2K issue is.  The internal
representation of the date is only one small Y2K problem.  The others
include:

 - are the library functions robust?  Are they correct?  (E.g.,
   can they tell you whether 2000 is a leap year?  The date of
   Memorial Day in 2017?  The date of Easter in 2004?  The number
   of business days between any two arbitrary dates?)

 - do the developers actually call these functions, or do they
   write their own?

 - do the developers always display 4-digit years?  If not, do they
   always truncate the year correctly?

 - do the developers alway require 4-digit years?  If not, how do
   they interpret shorter years?

Bottom line: if mac programs are intrinsically Y2K safe due _solely_ to the
representation selected by the godlike system designers at Apple, then all
C++ programs are intrinsically bug free and fault tolerant since that
language was designed to include resources to help make software engineering
manageable.

Bear Giles  bear@indra.com


Re: Macintoshes and Y2K (Wood, RISKS-18.78)

Jonathan Stott <RFC822@poly.phys.cwru.edu>
23 Jan 1997 17:58:56 GMT
Ahh, but how do your _applications_ store dates?  If only the last two
digits are stored on disk then you have a problem, no matter how many bits
your system clock uses.  Good hardware design only provides a false sense of
security when the programmers get sloppy.

Jonathan Stott, CWRU Dept. of Physics, School of Graduate Studies
jjs17@po.cwru.edu jstott@poly.cwru.edu http://poly.phys.cwru.edu/~jstott/


Y2K on non-Unix/Microsoft systems (Wood, RISKS-18.78)

Steve McKinty Sun Microsystems Grenoble <smckinty@sunicnc.France.Sun.COM>
Thu, 23 Jan 1997 15:05:49 +0100
This isn't particularly novel. DEC's VMS operating system (designed in the
mid-1970s) also implements the date as a 64-bit signed integer giving the
number of microseconds since the Smithsonian base date of (I think) 17th
November 1858.  +ve numbers are regarded as absolute values, -ve ones as
deltas, but even so the VMS clock is good for many millenia.

In addition to that all date displays use a 4-digit year. There is a
well-known bug filed against VMS pointing out that the date displays will be
incorrect after Dec 31st 9999. The bug was accepted by DEC with the note "we
will fix this in a future major architecture."

Steve


Re: Y2036, Y2038, and the superiority of UNIX (RISKS-18.78)

"Frederick G.M. Roeber" <roeber@netscape.com>
Fri, 24 Jan 1997 01:57:37 -0800
In RISKS 18.78, Dan Hicks wrote:
> I prefer a floating-point format ...

Note that if you are measuring intervals by subtracting timestamps, then the
use of floating point numbers for the timestamps can lead to hard-to-debug
errors in accuracy.

The Patriot missile failure in Dhahran was caused by a similar error: values
from the system clock (integer number of tenths of seconds since powerup)
were converted into floating point values to do the intercept math.  After
some number of days of operation, the point floated, and the accuracy
suffered.  [See RISKS-13.35]

While it can be argued that this merely means that intervals should not
be measured by subtraction like this, I think that floating-point system
clocks would only increase the RISK of such an error.

Frederick G.M. Roeber, Netscape Communications Corp., 501 E. Middlefield Rd.
Mountain View, CA, USA-94043 +1 (415) 937 3180 roeber@netscape.com


URL filtering, Re: ad.doubleclick.net (RISKS-18.78)

Caveh Frank Jalali <caveh@Eng.Sun.COM>
Thu, 23 Jan 1997 14:15:38 -0800
The obvious defense against hostile or undesirable web sites is to not visit
them in the first place.  This process can in fact be automated in
netscape's browser.  This saves bandwidth and your time!

The basic premise is that the browser may optionally execute a function on
every URL before it is accessed to determine whether a direct connection
should be made or a proxy should be used in the process.  This affords the
opportunity to [mis]direct the browser to fetch the document from an invalid
source.  this is a good approximation of not getting the document at all.

We sit behind a fire wall, so all WWW access has to funnel through a
proxy.  If I tell netscape to fetch an external document using a
direct connection, the connection attempt will fail, and the document
will not be accessed.  Netscape will put a broken image icon in its
place.

Here are the nuts and bolts to do it, but some assembly is required:
Under options/network preferences/proxies, select "automatic proxy
config" and tell it which file to use.  Call it something like
"file:///HOMEDIR/.netscape/proxy.pac", replacing HOMEDIR with your
home directory; the actual code is included below.
Next, go to options/general preferences/helpers and create an
application helper of type "application/x-ns-proxy-autoconfig" for
suffix "pac", handled by "navigator".
Install this java-script code to do the actual filtering.  call it
"file:///HOMEDIR/.netscape/proxy.pac", as mentioned before.

================
function FindProxyForURL(url, host) {
    if ( isResolvable(host) && ! shExpMatch(host, "[0-9]*") )
        return "DIRECT" ;
    else if (host == "advertising.quote.com")
        return "DIRECT" ;
    else if (host == "ad.doubleclick.net")
        return "DIRECT" ;
    else if (shExpMatch(url, "*:*/ads/*"))
        return "DIRECT" ;
    else
        return "PROXY webcache:8080; ";
}


Guilty by confusion? Domain names and IP addresses of net.abusers

Lars Wirzenius <liw@iki.fi>
Thu, 23 Jan 1997 12:08:32 +0200
Net.abuse (spamming, mailbombing, systematic trolling, etc) are being fought
via filters, among other things. This leads to unexpected risks for innocent
bystanders.

Having a similar domain name as a known net.abuser can make you guilty by
confusion: if a spammer operates from earthFOO.com, and you are
earthBAR.com, people are going to confuse the two domains.  This has already
happened (for suitable values of FOO and BAR -- the common earth prefix was
actually used).

If it happens in a discussion, it can be (and has been)
corrected.  If it happens in a router, filter, or other software,
it can be difficult to even detect.

A similar thing applies to IP numbers. Many sites now block all IP addresses
belonging to problematic sites. If at a later date those addresses are
reclaimed by the ISP and re-assigned to another client, that client will
still be blocked. Given the worries about IPv4 numbers running out,
especially for smaller ISPs, this isn't unthinkable.

I have an aggressive junkmail filter (http://www.iki.fi/liw/mail-to-lasu.html)
You don't have to worry about it, since I've sent you mail.

Adios ads.doubleclick.net

< Fri, 24 Jan 1997 11:29:38 -0600
I put the following in my /etc/hosts (yea, unix-centric, too bad):

127.0.0.1 localhost ad.doubleclick.net

End of problem.  I suppose if not already running a WWW server
one could even put in a simple script invoked by inetd :

#!/bin/sh
echo "Content-type: image/gif"
echo ""
cat /usr/local/etc/nyah-nyah-nyah.gif

if it makes you happier....

I suppose the risk is if ad-avoidance becomes popular enough that browser
makers make it easy, then everyone does it, then an unintended consequence
might be the hastening of the "pay-per-viewing" of the internet.

John


Side benefit of proxies re cookies

Mark Seecof <Mark.Seecof@latimes.com>
Fri, 24 Jan 1997 18:03:30 -0800
A side benefit of proxy-server/firewalls is that they somewhat mask the
identity of web-browsing folks behind them.  When I refuse cookies and
access Internet resources through the firewall of a large organization I get
much of the anonymity I might want.  I suggest that ISP's should offer to
proxy their small customers' browsing just to give them this benefit.


Risks of communicating with the wrong person

"James W. Birdsall" <jwbirdsa@picarefy.picarefy.com>
Thu, 23 Jan 1997 20:19:11 -0800
Actually, the risks of misaddressing occur in any communication medium.  We
all receive paper mail that isn't for us; since most of us check addresses
before opening mail, privacy is usually preserved at least (as it would be
if we used the electronic equivalent of envelopes -- encryption).  We all
receive phone calls that aren't for us; since the telephone is an
interactive medium it is customary to verify the identify of the person at
the other end before exchanging messages, thus preserving privacy and
ensuring that the message reaches the right person.

In 18.77, darin@connectnet1.connectnet.com (Darin Johnson) writes:
>The old rule applies - never say anything on usenet or e-mail that you
>wouldn't mind being posted in the office lunchroom.  Chances are, it just
>might end up there.

Actually, the place where this event is most common is on the MU* (MUD,
MUSH, MUCK, MOO, MUX, etc.) systems, where it is known as a "mav". When
sending a private message (page, whisper) to someone, it is very easy to 1)
send a message to the wrong person, typically somebody else you are talking
to or 2) mistype the command so everybody in the room sees the message. On
fancier systems which allow a user to automatically reply to the last person
who paged them, it is common (especially when the net is lagging) to get a
page from person B while typing a reply to person A and thereby accidentally
send the reply to person B.

Despite a lot of fallout and embarrassment from these incidents, nobody has
come up with a good way of reducing them -- if people won't double-check
what they type, there's nothing software can do to save them.

Also in 18.77, Lawrence.H.Smith@williams.edu (Lawrence H Smith) writes:
> ... naive users perceive it as "like paper mail, only faster and cheaper" -
> a perception which is deeply flawed.

Actually, the perception that paper mail is reliable is deeply flawed.
Comparing the performance of the US Postal Service to that of the net in my
nine-plus years on the net, I would have to say that paper mail is at least
as bad if not worse. The post office loses several pieces of mail on me
every year. Their latest goof-up was to misdeliver a piece of mail to the
wrong address (wrong *state*, even!) three times before bouncing it back to
me. Now, this failure mode is shared by electronic mail, but the post office
took two months as opposed to a few hours.

   --James W. Birdsall


E-Mail Addressing Problems

Todd Burgess <tburgess@uoguelph.ca>
Thu, 23 Jan 1997 23:07:10 -0500 (EST)
The university of Guelph has a simple policy for creating e-mail accounts:
first initial, last name (i.e., tburgess@uoguelph.ca). This scheme works
great as long as their are no duplicates (ie Tom Burgess). If there are
duplicates then they start adding numbers to the e-mail ID or simply using
first names.

When my brother came to Guelph my Dad tried sending e-mail to
jburgess@uoguelph.ca which was not my brother's e-mail account. My brother
had been given the account joel@uoguelph.ca. Luckily the person who got the
e-mail was nice enough to look up the correct address and forward it to my
brother.

The RISKs? E-mail ID schemes like this work great as long as there are no
duplicate names. The moment there are duplicate names then a lot people are
going to start seeing other people's e-mail.

As for Kamens's (RISKS 18.78) comment about paper mail vs. e-mail. I think
it would be fair to say that it is easier to get an e-mail address wrong
then a paper address wrong. E-mail delivery systems only have the e-mail
address to go on when delivering mail. If your e-mail ID doesn't match then
tough it bounces.

Mail addresses have fields like name, address, city, country and postal code
to assist in delivering mail. Failing that post offices can open mail in
hopes of finding the correct address. I know people who have worked in post
offices in small towns and they say they can usually determine where to send
a letter simply on the name alone (even if the address is incorrect or
missing).

University of Guelph, Computer Science Major   E-mail: tburgess@uoguelph.ca
URL: http://eddie.cis.uoguelph.ca/~tburgess


Verifying Mail Addresses

David Fetrow <fetrow@biostat.washington.edu>
Fri, 24 Jan 1997 21:26:55 -0800 (PST)
In RISKS-18.78 Mike_Perry@DGE.ceo.dg.com and others discuss the problem of
verifying e-mail addresses as correct, rather than just hitting the send key.

The obvious solution ("Do you really want to send this? y/n") would
undoubtably work no better than it does for file deletion.

It occurred to me that perhaps what's needed is verifying something besides
words on the screen; that if I am dealing with two kinds of sensory data
something is more likely to click. e.g. a voice saying:

"Sending mail to Ann Landers <al@annland.org>, OK?" and my saying "yes" or
"no" (well within a modern machines abilities). Perhaps even do a little
scan for hot words and have it ask: "Do you really want to use the word
'braindead' in your mail to 'boss'?".

Although this is probably silly regarding e-mail (and adds a host of risks
of its own) such warnings attached to particularly risky commands and
forcing a person to do something *unusual* to continue could prevent a lot
of errors, if not overused.

(Note, something similar happens when the WinNT 4.0 license appears on the
screen while installing that product. To continue you have to hit F8, and
only F8. You are pretty much forced to at least glance at the license in
order to continue. Annoying but rather slick. Taking it one step further:
the key could needed could be chosen at random from the non-letters.)

David Fetrow, Biostatistics, University of Washington


AOL software flaw (Re: PGN comment in RISKS-18.77)

JMFBAH <jmfbah@aol.com>
Thu, 23 Jan 1997 09:30:15 -0500 (EST)
> ... AOL seems to have shot itself in the foot by going to flat-rate charges.

Complicating the access problem (which I haven't experienced personally) is
that AOL keeps putting up a piece of software that seems to block internet
traffic.  Despite repeated attempts to explain the problem, this software
still appears (almost every other day) without the original problems getting
fixed.  I believe it's very hard to determine whether the new pricing has
anything to do with their problems as long as they keep putting up software
that doesn't work.

/BAH


4th ACM Conference on Computer and Communications Security

Mike Reiter <reiter@research.att.com>
Thu, 23 Jan 1997 22:03:33 -0500 (EST)
        *** EARLY REGISTRATION DISCOUNT ENDS JANUARY 31 ***
    Fourth ACM Conference on Computer and Communications Security
               (Preliminary Technical Program)
                     Zurich, Switzerland
                      April 1-4, 1997
                   Sponsored by ACM SIGSAC

For more information, including registration and hotel information,
see: http://www.zurich.ibm.ch/pub/Other/ACMsec/index.html

  [The program looks really interesting.  PGN says, "check it out."]

Please report problems with the web pages to the maintainer

Top