The RISKS Digest
Volume 19 Issue 8

Tuesday, 15th April 1997

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…


Bizarre case of techno-harassment
Fake "PGP CRACKED" message lures users into trap
Derek Ziglar
When BC: really means CC: in e-mail
David Kennedy
The risk of a personalized act of kindness
Sam Lepore
New Trolling Scam on MSN
David Kennedy
IVHS vehicles and safety assumptions
Rich Mintz
Re: Parkers pass out
Simson L. Garfinkel
Re: Computers are usually right!
Bob Morrell
Y2K scenarios: a call for a vote
Bob Morrell
More on GMT vs BST: RS6000
David Alexander
Re: GMT, BST, and "current civil time"
John Styles
Martin Minow
Re: Standard to Daylight and back
Sergio Gelato
Risks of not using Ridiculously Priced Technology
Sara Thigpen
Re: RISKS of Mail Merge for Ontario Tories
Tim Kuehn
Info on RISKS (comp.risks)

Bizarre case of techno-harassment

"Peter G. Neumann" <>
Tue, 15 Apr 1997 08:10:48 PDT
One of the more troubling RISKS cases has been going on for the past four
months in Emeryville, Ontario.  Debbie and Dwayne Tamai have been stalked by
someone with clandestine electronic access to their house who has been
eavesdropping on their conversations, accessing their voicemail, changing
their TV channels, and turning electricity on and off.  The electronic
intruder (``Sommy'') has interrupted phone calls, taunted the Tamais,
flaunted police efforts, and eluded electronics and surveillance experts
trying to determine how all this is happening.  After each time that Bell
Canada rewired the house, Sommy was quickly back in business — once within
20 minutes.  Also, an attempt was made to put 600 volts on the phone line
while Sommy was connected.  Debbie said that Sommy just laughed, and said
``What are you trying to do, zap me?  I've got a backup system, stupid.''
He also bragged to the Tamais that his house was one that been visited
during a door-to-door police search of the neighborhood.  That should narrow
it down a little!  [Source: An Associated Press item, seen in the *San
Francisco Chronicle*, 15 Apr 1997, A8]

There is speculation that perhaps not-so-good-neighbor Sommy did some
creative wiring of his own while the Tamais' new house was being built, and
that he is hacking in via a nearby BC wiring station and/or underground

Fake "PGP CRACKED" message lures users into trap

Derek Ziglar <>
Tue, 15 Apr 1997 12:06:57 -0400
[The following was reported in _Netsurfer Digest_ (April 13, 1997 - V03
N12), a source normally known for passing on only reliable information.]


A particularly elegant bit of trickery is winding its way through a favorite
newsgroup near you. It appears in the form of a provocative HTML message
excitedly proclaiming that "PGP Has Been Cracked!" and gives you a link to
click for more information. In reality, the link leads to the Telnet (25) or
NNTP (119) ports of a certain ISP, where the really elegant part comes
in. It appears that this provider regards your attempt to access these ports
as an attempted hack. Furthermore, it is quite anal about complaining to
your own ISP that you tried to break into their machines. A clueless
netsurfer (that would be you) could lose his account if his own ISP is of
the "kick off first, ask questions later" school of customer service. How
this great mind hack plays on the paranoia of all involved is what so
enthralls us. Read about it in the <news.admin.censorship> group.

  [There was also an apparent April Fools' item, ``RUMOR about large-number
  factoring in polynomial time'', citing a result attributed to Sergie
  Ripov.  It was submitted by "Mike Giroux" <>, but
  does not break any new ground, even in April Fools' Spoofs.  PGN]

When BC: really means CC: in e-mail

David Kennedy <>
Tue, 15 Apr 1997 02:21:00 -0400
(Courtesy of passed to me by NCSA's IS/Recon

Microsoft Office 97's PIM is called Outlook 97.  It can be used to send
e-mail.  The message software has the apparent ability to send Blind Copies,
but when actually used, the addressees are visible to all recipients.

MS promises a patch next month.  (DMK: Is there an echo around here?)

> "This offers potential for major embarrassment," said Steven Bang,
> Webmaster at Inc., who found the bug this morning.
> [ can be reached at]

Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.

  [The e-mail copies are not blind, but the software is visibly impaired.  PGN]

The risk of a personalized act of kindness

Sam Lepore <>
Mon, 14 Apr 1997 20:16:10 -0700
I decided to perform a 'random act of kindness'. I went to a Hallmark card
store to create a personalized greeting card for a friend to remember a
romantic 'non-event' in our past. To create a personalized card, you choose
a blank sample and enter the text you want on a PC screen, then take the
blank to the counter to be finished on a laser printer.

One of the questions asked during the customizing script is "your initials"
to identify your card among others at the counter. I chose two random
letters. (I wonder now whether it would have accepted numbers?)

After the card was done, I chatted with the clerk for a while to be
friendly, then asked how long the text of the personal message was kept on
the computer. She said it used to be kept until they ran out of space and
began recycling, but now it is only kept for 5 days because of "the false
arrest". Huh ??

This is all unsubstantiated, but it is her story ...

She explained that some (unspecified) time ago, a customer had made a
threatening card, after which an assault had been committed. When the police
investigated the evidence of the threat, there was some confusion of which
customer had paid for the threat card. It seems that, like me, the
threatening customer chose initials that did not belong to him. But the
initials he chose happened to match the name of either the previous or next
customer who paid for his/her? card with a credit card. That person was
identified and 'arrested' as the assaulter. When the mistake was realized,
the falsely accused threatened suit against the store ...  and now the store
wipes computer records (on average) before the police can get to them.

Risk? Since the computer never makes a mistake, you did it unless you can
prove otherwise (standard data entry *verification* problem). And no, the
clerk never noticed that the initials I chose did not match the name on my
credit card.

Privacy? If you get _really_ personal in a customized card, the store staff
can and probably does enjoy your message vicariously. She did mention that
'you ought to see how bad some of these people write!'.

Sam Lepore, San Francisco

  [She must be a great-gramma(r).  PGN]

New Trolling Scam on MSN

David Kennedy <>
Tue, 15 Apr 1997 02:20:50 -0400
(Courtesy of BugNet passed to me by NCSA's IS/Recon analysts.)

BugNet Alert --

Credit Card Scam Hits Microsoft Network

> MANY USERS of the Microsoft Network (MSN) report they have recently
> received fraudulent e-mail from the "MSN Billing Department" which is
> designed to steal their credit card numbers.

The e-mail claims a virus wiped out MSN's billing records.  Virus was
allegedly introduced by an ex-employee.  The e-mail states that, due to a
virus unleashed by a "malicious ex-employee," all the billing records of MSN
have been destroyed.  It asks for the usual information, allegedly so that
MSN can report it all to the FBI.

> To try to give the request the air of legality, the message continues:
> "*NOTE* If you reply with credit card information other then your own,
> your account will be canceled, and we will submit all information on you
> available to us to the Credit Card fraud department of the F.B.I."

MSN has denied the story and is trying to identify those responsible.

Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.

IVHS vehicles and safety assumptions

Rich Mintz <>
Fri, 11 Apr 97 18:15:08 -0400
A discussion on another list (Pednet, on issues of concern to pedestrians;
contact me for subscription info) recently turned to the subject of IVHS
(Intelligent Vehicle Highway Systems) — intelligent road-vehicle
combinations which control the flow of traffic with no or limited operator

In that forum, one poster (whose words I am quoting without permission, so
I'll accept and forward messages on his/her behalf) noted one conceivable
advantage of such systems that no one had thought of:

<>2. The even newer technology that would allow the car to "read" the road
<>ahead to prevent it hitting anything could be used by pedestrians to get
<>across the road.  After a healthy wait fails to produce a break in the flow
<>of vehicles, the pedestrian could simply start off, knowing that the cars
<>would apply their own brakes and come to a safe stop in time.

Reading this, I was intrigued by what seems to be a fascinating idea, and at
the same time the RISKS alarm bell went off in my head.  This seems to me to
be just another version of the aircraft or railroad automation problem, only
in reverse: rather than (A) the automation causing the operator of the
vehicle to lose his or her alertness, thus contributing to more serious
problems at the occasional times when the system fails (another problem
which, incidentally, also applies in this case), the Pednet poster has
identified a case in which (B) the automation causes _other parties_ (not
the operator) to make assumptions about the behavior of the vehicle, which
could conceivably turn out to be incorrect and hurt someone (in this case,
the person doing the assuming).

In fact, we make assumptions about the behavior of external objects all the
time.  We do it whenever we move to get out of the way of a falling object,
taking for granted that the laws of physics will continue to apply until it
hits the ground (and that it won't, say, suddenly speed up or turn the other
way).  We do it when we wade in the lapping waves at the seashore, taking
for granted that the sea won't suddenly rise up 12 feet in the air and
swallow us; we do it when we swim in the river, making an assumption that
the current won't suddenly quadruple in force and drown us.  And so on.

We even do it in the road; I cross the street in the face of oncoming
traffic, as long as it's sufficiently far away for me to know that if the
operator doesn't apply his brakes in time, I have time to run fast and get
out of the way.  I trust the laws of physics and the limits of automobiles
enough to know that even if an errant driver floors the accelerator, his/her
potential acceleration is limited (he/she won't do zero-to-60 in 0.25
seconds, for example) and I can still get out of the way.

But once software systems take over, some (not all) of these bets are off.
The Pednet poster is postulating a world in which people have become so
trusting of safety systems, and so trusting, that they're willing to step
off the curb into oncoming traffic, too fast or too close to get out of the
way of, _and assume the traffic will stop_ — in which they come to depend
on the system to save them from themselves.  They're no longer saying "the
laws of physics protect me, because I can safely assume that a body in
motion will continue on the same path"; they're saying "the laws of physics
are irrelevant, because I assume that an outside entity will intervene and
_stop_ that body in motion before it hits me."  (I'm not "accusing" the
Pednet poster of that type of "trusting," merely of bringing up the subject.

I see that type of "trusting" as qualitatively different from the sort I go
through every day: for instance, getting in an elevator, even though I don't
know how an elevator works, and assuming that the cables won't snap and drop
me to my death.  In the case of the elevator, the laws of physics act to
calm me (I know that cables have a certain tensile strength, and gravity
exerts a certain pull, and anecdotally understand [or think I do, anyway --
yikes! Tonight I'm taking the stairs] the sorts of fail-safe systems built
in, in which gravity acts as a last resort to stop a falling car by exerting
some sort of pressure on some sort of widget and causing the car to brake
against the side of the shaft; and assume the inventors of the elevator took
all these things into account in proper proportion).

Perhaps it's only a matter of time before dashing in front of an oncoming
car and expecting it to stop becomes as much "second nature" as stepping
into an elevator.  (Once upon a time, stepping into an elevator was

Rich Mintz - - Arlington, Virginia USA

Re: Parkers pass out

"Simson L. Garfinkel" <>
Mon, 14 Apr 1997 17:07:55 -0700
Michael O'Donnell's posting to RISKS-19.07 about the management of his car
garage believes its computer rather than its customers was revealing. "She
did let us all leave eventually, but never seemed truly convinced that we
had not gotten away with some cunning trickery," O'Donnell writes.

I'd like to suggest to O'Donnell --- and to all other readers of RISKS ---
that when things like this happen, the appropriate response would be to call
the local newspaper. These sort of stories make great copy for the local

Rather than giving lectures about computer RISKS to low-level managers, who
frankly don't care, give them to reporters, who will be happy to share them
with their readers.

The only way to solve these problems is by public education. This is a
great way to do it.

Re: Computers are usually right!

Bob Morrell <>
Tue, 15 Apr 1997 12:04:28 -0700
RISKS-19.07 contained two "computer is always right" stories that at first
glance seemed to reflect the same old problem: people trusting a computer
when a more obvious answer is at hand. Closer examination of the two
articles reveals a fundamental difference between the two that RISKS readers
and the general public should learn to recognize.

Michael O'Donnell's problem with a parking lot computer encounter is the
typical "computer is always right" story. An unusual computer alert (the
suggestion of park-card "passing") is paired with a system crash.  An
innocent person is accused and the stubborn computer user fails to consider
that the computer might be wrong, or see the connection between the crash
and the alert. The key here is an =unusual= alert, which should cause any
computer-wise person to immediately question the computer before they cast
accusations about.

This contrasts sharply with Joe Carlet's child's library fine story. In this
instance the librarian was faced with a very common computer alert (an
overdue book) Here, it would be very counter-productive to question the
computer every time (indeed, if that were the case, then one should get rid
of the computer). Mr. Carlet was in an unusual situation in that he could
prove his child's innocence, and is to be commended for hanging in there
against a stupidly designed system. The librarian however is not due scorn
for being at least initially unreceptive to his pleas of innocence. How
often do you think he or she has heard this before, only to discover that
the computer was right? Almost any computer system user can tell you of
vehement pleas of innocence to be followed later with sheepish admission of

The key element here is recognition of what is unusual: the flag or the
falseness of the flag. When the flag is unusual, it is incumbent on the
system operator to check things out. When it is the falseness of the flag
that is unusual, it is the responsibility of the accused to check things out
carefully (in my experience as an indignant accused, I usually turned out to
be wrong) and to be patient with system operators that may have several
levels of denial to go through before they take seriously the possibility of
error. This is both human nature and efficient time management. It is why we
have FAQ phone trees (despite the fact that your problem is "unique").

The RISK here is that without this distinction, computers, like an
untrustworthy person, will not be worth using at all.

Bob Morrell

Y2K scenarios: a call for a vote

Bob Morrell <>
Thu, 3 Apr 1997 10:27:49 -0500 (EST)
While this and other forums have been focusing on the technical details of
the year 2000 problem. I think that it would be good to take a step back and
assess exactly what the problem will look like, say in the year 2005. That
is, what kind of historical event is this really going to be?  RISKS, which
has as its audience people who deal with computer problems and their
resulting headaches seems an ideal place to have an extended thread on this
issue, identifying scenarios and casting informed votes on their likelyhood.
Here is my list of scenarios and my vote

NON-EVENT: In this scenario, all the fretting and reprogramming pays off, or
alternatively, computers turn out to be less important than we thought.
Problems are solved with a little foresight, or with common sense after the
fact. IS workers pull a little overtime the first week watching for trouble,
but nothing unmanageable turns occurs. It is even conceivable that a positive
boost could occur as businesses and governments get a more detailed
understanding of the limitations of their computer systems and replace long
neglected programs with software that adds utility to their systems.

SPEED BUMP: This is the scenario that most news organizations seem to be
expecting. Problems occur, but because everyone is expecting it, we slow
down and go over the bump without real damage. Snafus appear, and businesses
apologize for the error. The event becomes the national equivalent of April
15th (tax filing day), with many headaches, much griping, but in the end,
the work is done, and we return to normal speed quickly.

SLOW DRAG: Just as problems with the year 2000 appeared years before, in
this scenario, problems will appear over time after 2000. As daily, weekly,
monthly, quarterly, yearly programs encounter the problem, there is a
constant but only slowly realized drag on all activities. In this scenario,
everything done for the first time after 2000 will be problematic, and
delays, errors and decreased productivity will diffuse through the economy,
not always attributable to the year 2000 problem. The drag could be as
significant as an increase in tax rates or energy prices.  The year 2K could
result in a recession, but the connection might not be obvious.

BLIZZARD: In this scenario we come into work on Monday after the revelries
to find 4 feet of computer snow on our desks. Computer and physical systems
associated with them crash, there are traffic snarls, power outages and
other significant problems. "Revert to manual methods" becomes the
byword. The most significant aspect of this scenario is that all the
problems (like the snow) is on the ground, and we all know what it is we
have to work through. Power is restored, backup files found and used, and
everyone shakes their heads in amazement at how reliant on computers we have

HURRICANE: In this disaster scenario physical and technical problems abound,
and new ones are continually being found. The problems threaten physical
harm to the public. Before events can cascade governments intervene. Bank
holidays are declared, food shipments and other essential activities are
taken over government mobilized noncomputerized troops or bureaucrats. All
normal commerce ceases till hastily constructed emergency systems can
provide society with basic needs. Emergency councils are convened, and while
it is a physical disaster like a hurricane or flood, everyone understands
what is needed to reconstruct and begin anew.

APOCOLYPSE NOW: This scenario has all the disaster components mentioned
previously, but has added to it a substantial public panic. Problems cascade
beyond informational, beyond physical, to the psychological and
sociological. Stock markets collapse, rioting in the streets occurs,
governments fall, and societal constraints break down.

My vote is for the "slow drag" scenario.

More on GMT vs BST: RS6000 (re: RISKS-19.07)

David Alexander <>
Tue, 15 Apr 1997 09:03:31 +0100
I work with IBM RS6000 systems which run AIX, the IBM Flavour of UNIX. In
spite of the fact that it is possible to set the time-zone to:

  (GMT0BST)           United Kingdom               (CUT)

The dates the time changes from GMT to BST and vice-versa are wrong. The US
programmers always assume that our dates for time change are the same as
yours, so rather than an automated hassle-free changeover, we have to
correct the time 4 times a year to ensure the time-stamps in applications
run correctly. The RISK is one of not bothering to research the facts all
the way through. In spite of IBM having been formally notifying twice a year
for the last 2 years, they have done nothing about it.

What was that old adage about a stopped clock being right twice a day ?

David Alexander, Caplin Cybernetics Corporation, Windmill Business Village
Brooklands Close, Sunbury-on-Thames, Middlesex TW16 7DY, England 01932 778172

Re: GMT, BST, and "current civil time" (Brader on Bacon, RISKS-19.07)

"John Styles" <>
Tue, 15 Apr 1997 10:12:01 +0000
GMT certainly does not mean 'the current civil time in the UK', for which
there is, as you correctly note, no term.  I think that persuading people
that it would be a neat idea to have a different name to call the time we
use in winter which is actually, but not conceptually, GMT, could be a bit
of an up-hill struggle.

John Styles

  [BST = British Summer Time]

Re: GMT, BST, and "current civil time" (Brader on Bacon, RISKS-19.07)

Martin Minow <>
Mon, 14 Apr 1997 22:43:34 -0700
It should be pointed out that the United States Naval Observatory
<> distinguishes between UTC and GMT (which is
currently one hour ahead of UTC). It would seem, then, that Windows 95 is
correctly advancing GMT when the user selects "adjust for daylight savings

That said, I've been trying to figure out the "right" solution to a Java
timezone problem. According to the published documentation for the Java Date
function, the getTimezoneOffset method returns "the number of minutes that
must be added to GMT to give the local timezone." If I'm not completely
confused, this means that Pacific Standard Time should have a timezone
offset of -480 (-8 hours).  However, every browser I've tried returns
+480. Documentation bug? Programming bug? What is the right solution?

Martin Minow

Re: Standard to Daylight and back (RISKS-19.07)

Sergio Gelato <>
Tue, 15 Apr 1997 16:04:13 GMT
>     And don't forget that the differences between UK local time and North
>     American east-coast local time change FOUR times a year because the
>     changes happen on different weekends.  PGN]

No, the summer->winter change now happens on the same week-end in both the
European Union (including the UK) and North America. The winter->summer
change is still off by a week. I suspect that the EU, having moved the end
of summer time from the end of September to the end of October to match US
practice, now expects the US to do a reciprocal gesture and move from the
first week of April to the last week of March. Anyway, the difference
changes only twice a year now: on the last Sunday in March at 0100 GMT, and
on the first Sunday in April (at 0700 GMT, I believe. GMT==UTC at all times,
as even casual listening to BBC World Service will confirm.) Unless you take
into account the fact that the summer->winter changes occur a few hours
apart (in which case you are right about the "FOUR times" but not about the
"different weekends" explanation for it).

  [Yes, indeed.  Incidentally, I do not recall a RISKS case of screwups
  resulting from the hour differences in the 24-hour period of cutover.  PGN]

Risks of not using Ridiculously Priced Technology

Sara Thigpen <>
Tue, 15 Apr 1997 08:22:26 -0400
I like Volvos for longevity and safety.  (After getting broadsided in the
passenger side front door and fender by an 18-wheeler Mack truck, I drove my
'78 wagon 200 miles home.  So I have great affection for these rolling
boxes.)  However, I don't believe in car payments, especially when a new one
would set me back a larger amount than my mortgage balance.  So our youngest
car is an '88 with >150K miles.

When the little "SRS" light suddenly lit up on the dash, I looked it up in
the owner's guide.  Turns out it's about the driver's airbag.  "See your
Volvo dealer" it says.  So I did.  I figured it'd be a switch, or a loose
wire somewhere, as happens with old cars.

Wrong.  It's "the chip", don'tcha know?  The one that senses a crash and
inflates the crash balloon.  The diagnostic shows it has an error code.
Doesn't matter which code, it needs a new one.  The price?  Nine Hundred
Dollars.  (Plus labor.)  It's gold plated, don'tcha know?

After I verified in triplicate that it will not fail by inflating the thing
when there is *no* crash, I decided not to replace it.  I always wear the
seatbelt and shoulder harness, and because I'm just under 5'3" the airbag is
probably a danger to me anyhow.

The Risk — what price safety, indeed?

Sara Thigpen

Re: RISKS of Mail Merge for Ontario Tories (Brader, RISKS-19.07)

Tim Kuehn <>
Mon, 14 Apr 1997 21:53:32 -0400
>In fact, one of these amendments was passed, [...]

This has been negated by the section of this bill that was dropped,
effectively deleting the amendment from the bill.

One of the interesting aspects to this is that for votes, the Legislature
normally gets locked, nobody in or out, and the MPPs stand to indicate their
vote yay or nay.  The speculation was that it would be come an endurance
contest to see how many MPPs could deal with standing up and sitting down
12,000 times during the voting period. The rules about nobody in, nobody out
were also relaxed to allow breaks every 4 hours for food, visits of
necessity, and the like.

The risks here are somewhat clear:

1) When a governmental system run by 19th century practices runs into an
automated opposition, it's the people who'll suffer - in particular the
government employees who work behind the scenes.

2) Future MPPs may need to spend more time in the gym so they can handle
these marathon voting sessions.

3) This tactic will almost certainly be addressed by the government to keep
it from happening again - possibly with damaging effects for the democratic
process when issues might be raised in a similar manner but for non-stalling

>Presumably, the next time this sort of thing happens, the computers will be
>programmed to produce a more varied set of amendments, to defeat the "only
>read the changing part" technique used this time.

Or the rules of the house would be changed to allow for an automated
governmental vote on automatically generated amendments, thus reducing the
sitting of the house to two Soundblaster-equipped PC's - one to read the
amendment, the other to say "No", while the rest of the MPPs do whatever
they do.

Tim Kuehn  TDK Consulting  Kitchener, Ontario

Please report problems with the web pages to the maintainer