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 19 Issue 31

Tuesday 19 August 1997

Contents

o Quag-Mir: Mere-ly more challenges to overcome?
PGN
o Mir-ed in Troubles
Fred Baube
o e-mail spam equivalent to computer cracking?
Fred Gilham
o A risk of not preventing spam relay
Dennis Glatting
o Credit reports misdirected
Steven Bellovin
o "Crack a Mac" server cracked
Martin Minow
o SET risk
Jerome Svigals
o Bell Canada: The Computer is Always Right
Steve Keppel-Jones
o Machines make nuisance phonecalls
Lloyd Wood
o Push technology in the office
Ken Burchill
o Unusual computer system denial of service: water
Mark Forsyth
o Czech Intelligence Computer Stolen
Pete Mellor
o Unsolved Mysteries covers identity theft!
Denis Parslow
o The Door Is Open!
Glen Roberts
o Insurance company billing error
Paul Green
o Re: Ctrl-Alt-Del
Li Gong
Morris Maynard
o Info on RISKS (comp.risks)

Quag-Mir: Mere-ly more challenges to overcome?

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Tue, 19 Aug 97 8:14:54 PDT
The occupants of the space station Mir have really been having a rough time.
The latest problem [19 Aug 1997] involved the failure of Mir's main computer
system during a docking attempt with an unmanned Progress supply ship,
necessitating a manual docking.  Without the computer system, Mir is
spinning and requires continual rocket firings for reorientation to keep the
solar panels directed properly.  The previous day, the automatic docking had
to be postponed because of the discovery of erroneous information sent to
Mir.

The June 1997 crash into Mir during a practice docking maneuver with a
Russian supply ship (with further compounding complications in the attempted
repairs) is being attributed to the failure of the cosmonauts to adjust the
automated approach controls to compensate for an extra ton of weight that
had been added to the cargo vessel.  Other recent problems were not computer
related -- an oxygen fire in February, failure of both oxygen generators in
March, an antifreeze leak in April, Vasily Tsibliyev's heart irregularities
in July, the accidental disconnecting of a power cable that effected Mir's
orientation system for a day also in July.  Earlier in August, the relief
crew had to make a sudden manual docking with Mir.  Subsequently, when
Tsibliyev and his flight engineer returned to earth, a booster rocket failed
that was intended to ease their landing.

[Sources: *Los Angeles Times*, 18 Aug 1997, and *Washington Post*, 18 Aug
1997]

The difficulties relating to the space station serve as another poignant
reminder of the vital needs for redundant system design, defensive
implementation, exceedingly careful system analyses (particularly with
respect to the normally unflexed emergency system complexity), alternative
strategies in operation, training to prepare for the most unusual
circumstances, and above all the recognition of the fact that computer
systems are only a part of an enormously complex infrastructure that
ultimately depends critically on people in many different roles.  PGN


Mir-ed in Troubles

F.Baube <fred@kirjasto.kaarina.fi>
Tue, 19 Aug 1997 13:44:09 +0300 (EEST)
There are documents on the Net describing the architecture of the Space
Shuttle's computers.  Are there any similar documents describing those of
Mir?  Something to help one understand just how grave (or overblown) the
current situation is?  Also, in principle the cosmonauts should be able to
use the Soyuz escape capsule in any situation, correct?  But the news says
that due to the current "computer failure", the station is "tumbling".  (No
mention of roughly how fast.)  Might this tumbling render the escape capsule
unusable, for whatever reason?  And in such a case, do they have an
alternative means to calculate what sorts of thruster burns are necessary to
return the station to a state where the escape capsule may safely be used?
Perhaps some hand-wound gyroscopes and a calculator?  (Something analogous
to the backup nav tools used on Apollo 13?)

F.Baube(tm)  G.U. MSFS '88  fred@kirjasto.kaarina.fi

  [Please send responses to Fred and RISKS.  I hope that some
  RISKS readers will have the knowledge that Fred is seeking.  PGN]


e-mail spam equivalent to computer cracking?

Fred Gilham <gilham@csl.sri.com>
Mon, 18 Aug 1997 10:04:45 -0700 (PDT)
The following are headers in a spam message we received recently.

========================================
Received: from morse.satech.net.au (morse.satech.net.au [203.56.210.66])
  by csla.csl.sri.com (8.8.6/8.8.5) with ESMTP id QAA05236;
  Sun, 17 Aug 1997 16:53:34 -0700 (PDT)
>From: mailhost@aol.com
Received: from box.satech.net.au (root@box.satech.net.au [203.1.91.3])
  by morse.satech.net.au (8.8.5/8.8.5.SAT.GJR.970426) with ESMTP id JAA19120;
  Mon, 18 Aug 1997 09:26:25 +0930
Received: from satech.net.au (slip166-72-12-169.us.ibm.net [166.72.12.169])
  by box.satech.net.au (go-away/8.6.9) with SMTP id JAA28085;
  Mon, 18 Aug 1997 09:25:53 +0930
Received: from mailhost.101moneyserve.com by 101moneyserve.com (8.8.5/8.6.5)
  with SMTP id GAA01925 for <credit@101moneyserve.com>;
  Sun, 17 Aug 1997 19:56:45 -0600 (EST)
Date: Sun, 17 Aug 97 19:56:45 EST
To: credit@101moneyserve.com
Subject: Your Credit Report
Message-ID: <92375964576SSA61080@101moneynet.com>
Reply-To: credit@101moneyserve.com
X-PMFLAGS: 479309472 9
X-UIDL: 8152700109sdf3q099ity712y5a3c
Comments: Authenticated sender is <credit@101moneyserve.com>
========================================

Note that the `From:' address appears nowhere else in the headers, the
message was relayed, and the apparent origin of the message was an ibm.net
site that masqueraded as satech.net.au so it could relay the message through
satech.net.au's SMTP server.

The sender of this message clearly intended to have the message appear on
machines that would otherwise filter it out.  The sender resorted to fraud
to induce satech.net.au's mail server to forward the message.

Isn't this in violation of the U.S. federal law that prohibits people from
unauthorized access to computers?  Didn't the sender INTEND to access such
computers, in clear knowledge that the access was unauthorized?

Why isn't the sender guilty of a felony (CSL-SRI's computers are used in
government projects)?

Fred Gilham   gilham@csl.sri.com

  [Perhaps some of our Australian readers can say
  whether any of *their* laws were violated!  PGN]

    [Incidentally, apologies once again to any RISKS readers whose ISP
    is being blocked from sending mail to RISKS as a result of the
    overabundance of spamming activities from that ISP.  PGN]


A risk of not preventing spam relay

Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Fri, 15 Aug 97 08:48:09 -0700
Yesterday I received a spam mail. I replied with my usual piece of
unauthorized use of corporate resources to "abuse" and "postmaster" at what
I believed to be the offending domain (sometimes it's sometimes difficult to
filter through the forged components of spam headers), who I'll call
foo.com. I then added the foo.com to my spam block. The message to abuse and
postmaster bounced. I was annoyed. How dare they pontificate abut freedom of
speech then deny mine, I felt. I investigated.

My three minute investigation found foo.com's billing and technical contacts
and over 10 other peoples' e-mail addresses and home addresses at
foo.com. So I sent the technical contact my usual piece. Hah! I
thought. Shortly thereafter I noticed a message from a person later
identified as Bill, the Vice President of Technology at foo.com, bounced by
my spam block. Strange, but good! I thought. Shortly thereafter I received
the message from Bill! Bill used an account identified from a library to
apologize and indicated they were the victim of relay.

This is both a privacy issue and a risk. Company's not denying relay could
be putting their employees at risk, since their names and addresses are
often readily available through the net these days.

-dpg


Credit reports misdirected

Steven Bellovin <smb@research.att.com>
Mon, 18 Aug 1997 08:02:34 -0400
Experian, a credit bureau formed by the merger of TRW's unit and CCN Group,
started a new service offering consumers copies of their credit report over
the Internet.  A news story caused the load to skyrocket -- and the system
glitched under the load, causing some some of the reports to go to the wrong
person.

The system has been shut down until it can be fixed.  And of course, all the
usual concerns about privacy would apply even if it were working correctly.

  [Also noted by dbl@ics.com (David B. Lewis).  PGN]


"Crack a Mac" server cracked

Martin Minow <minow@apple.com>
Mon, 18 Aug 1997 08:32:52 -0700
The "Crack a Mac" contest <http://hacke.infinit.se/> was cracked by someone
who exploited a security hole in a third-party plug-in.  The cracker will
get the 100,000 Swedish Kronor (about $14,000) reward, and the software
plug-in's security hole was fixed in a little more than 24 hours. The second
person to break into their server will also get 100,000 SEK.

Apparently, the Web server uses files with specific creator and/or file type
codes to store sensitive information. The patch blocks these files from
being served. Creator and file-type codes are Macintosh-specific tags that
designate the application that process a file, and the semantics of the
file. There is more information about the patch on
<http://www.blueworld.com/lasso/security_update.html>

Martin Minow  minow@apple.com


SET risk

<smartcard@sprynet.com>
Sat, 16 Aug 1997 16:20:14 -0700
The Secure Electronic Transaction (SET) process is proposed by the
credit-card associations to secure credit-card usage on the Internet.  It
consists of a 28-step process using a standard digital certificate.  It
relies on vendor software to provide security.  These include an electronic
wallet program in the originator's PC, merchant review software at the
merchant's bank, card transaction processing software at the card issuer
bank and merchant software in the merchant's server.

The SET process claims to be better than using a credit card on the
Internet.  However, the SET process has three serious exposures - confirmed
with IBM and HP/Verifone. The process does NOT know who is presenting the
certificate.  The process does NOT know if merchant employees have
redirected the certificate through another merchant.  All of the critical
software is directly accessible by the card users, merchant employees and
bank employees.  Historically, these individuals have been the prime source
of fraud in credit card transaction systems.

There are more than 50 other card security products available for Internet
usage. They are generally simplier, faster, and avoid the SET exposures
identified above.  Internet transaction users might try the viable
alternatives.

jerome svigals, smartcard@sprynet.com


Bell Canada: The Computer is Always Right

"Steve Keppel-Jones" <stevekj@nortel.ca>
14 Aug 1997 22:44 EDT
A recent (RISKS-19.29) comment about "The Computer is Always Right" reminded
me of an incident a few years ago with Bell Canada.  I got a bill from Bell
with a number of calls to Uganda listed on it, totalling some hundreds of
dollars.  Of course, these calls weren't made by me, and from the times of
the calls, no one else could have made them either (I was living alone at
the time).  I don't think that anyone broke into my house and left no trace
except to make these long distance calls.  Confronted with this, Bell
insisted that I must have made the calls.  Pressed further, they revealed
that this particular bill had not been generated by the digital switching
software, but had been entered by *hand* - but Customer Service
categorically denied that a data entry error could have been made.  I just
about burst out laughing.

Naturally I didn't pay the bill.  The phone line was not registered in my
name and I was moving out shortly, so I simply ignored the problem in the
hope that it would go away.  I haven't heard anything from Bell about it
since.

The RISK is the usual one of non-technical people placing too much faith
in erroneous computer data - especially human-entered data.  GIGO...

Steve Keppel-Jones (stevekj@nortel.ca)


Machines make nuisance phonecalls

Lloyd Wood <L.Wood@surrey.ac.uk>
Thu, 14 Aug 1997 10:20:29 +0100 (BST)
This is presumably what happens when you don't test your error conditions
while installing a vending machine. Having to update and reprogram your
remote equipment every time the telephone service changes dialing codes is a
legacy problem.

The insulin refrigerator cited poses an obvious health risk.  LW

 - - - - - - - - -

Excerpt from 'On-line machines take the place of heavy breathers'
Robert Uhlig, Technology Correspondent, *Electronic Telegraph*, 14 Aug 1997

DEMANDING machines, including thirsty cold drink dispensers, a lonely oil
tank and faulty public lavatories have overtaken heavy breathers as the
telephone pests of the 1990s, British Telecom disclosed yesterday.

Although there has been a reduction in the number of obscene, malicious and
offensive calls since the introduction a few years ago of caller display and
callback service, more than 8,000 people a month were pestered by
wrongly-programmed machines trying to report faults to their operators in
the past year.

Anne-Marie Kennedy, national manager of the BT's nuisance call bureau, said:
"As technology improves, it is starting to cause a real problem. A few years
ago, nobody would have ever thought a drinks machine would be making phone
calls, but we've had a cold drinks machine that had run out ringing a
customer every few minutes and a medical fridge full of insulin trying to
raise the alarm because the temperature had fallen."

Other persistent pests include traffic lights, boilers, chocolate machines
in railway stations and the latest generation of lavatories, which call the
service company when they run out of cleaning fluids.

Mrs Kennedy said: "An elderly lady was rung up through the night by a public
toilet in a Leicester park." Unlike fax machines, which emit a distinctive
and piercing whistle, misdialing equipment is often eerily silent, leaving
receivers with no clues as to what - or who - is on the other end of the
line.

Mrs Kennedy said: "Whenever someone is programming a machine, if they hit
the wrong button, someone is going to get seriously annoyed. More and more
machines are being set up to self-diagnose faults and report them."

In an American case, a woman received nuisance telephone calls every 90
minutes night and day for six months from an empty oil tank in Maryland that
had been mis-programmed.

Mrs Kennedy said: "Many computers are now programmed to download all their
data to a central point overnight. If the operator gets one digit wrong,
some poor person gets one call after another throughout the night. It's very
irritating and down to nothing more than human error."  [..]

<L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641


Push technology in the office

<Ken.Burchill@PWGSC.GC.CA>
Wed, 13 Aug 1997 16:44:00 -0400
Anyone that works in a large, corporate environment that is linked to the
Internet knows that their LAN bogs down at lunch hour as everyone does their
daily surfing.  Any client-server application suffers as a result, with
increased response times during lunch.  This is usually of no great
consequence since the users are often at lunch (and surfing) too.

However, I wonder how what the impact of 'push technology' will be when
everyone turns their computer on at 9 a.m. and 5000 workstations
simultaneously begin downloading the latest OS upgrade.  It could take hours
to complete the downloads.  Meanwhile, the mission-critical, client-server
application is mired and practically unusable.  The risks to productivity
(and profitability) are obvious.


Unusual computer system denial of service: water

Mark Forsyth <Mark.Forsyth@adm.monash.edu.au>
Tue, 19 Aug 1997 16:49:01 +0000
This amused me a bit until I thought about it a bit more.

A large Australian organization went to HUGE effort to secure the computer
centre.  In particular the computer room is just about impossible to get
near let alone INTO without the correct security passes.  This security
worked extremely well UNTIL...

Imagine if you will walking down a city laneway and you spy a 4-inch water
main with valve.  After a little test it was ascertained that the valve was
indeed open. The person discovering this valve _thought_ it should be turned
off, and so it was turned off.  This was apparently done mid-afternoon on a
Saturday.  By Monday morning the computer room would have melted if not for
environmental alarms that notified NOONE but shut down the power to the
computer room.  Of course it transpired that the valve that the passer-by
had turned off was, in fact, the chilled water supply to the computer rooms
air conditioning.

I would have thought that the RISKS here are pretty plain for all to see.
It is not only essential that all services WITHIN a building are protected
from interference but that ALL service supplies to that building must also
be secured.

Mark Forsyth  mforsyth@ozonline.com.au


Czech Intelligence Computer Stolen

Pete Mellor <pm@csr.city.ac.uk>
Sat, 16 Aug 1997 16:01:41 +0100 (BST)
>From the CAROLINA electronic news bulletin by students of Charles
University, Prague, Friday 15th August 1997:-

Czech Intelligence Computer with Confidential Information Stolen

In May 1996 a worker from the Foreign Relations and Information Office, the
official name of the Czech intelligence service, had his personal computer
containing strictly confidential information stolen in a bar. The story was
made public August 5 by the Czech daily Pravo and was later confirmed by the
Interior Ministry.  Interior Minister Jan Ruml said the possible information
leak "does not threaten the running of the service or the security of its
workers or of the state," however Ruml is said not to have been fully
informed about the actual extent of the lost data.  The Prague State
Prosecutor's Office began investigating the case after an anonymous tip, and
the investigation should determine what data the computer contained.

To subscribe to CAROLINA news you send an e-mail message to the address
         LISTSERV@listserv.cesnet.cz
The text of message for subscription of the English version must be:
         SUBSCRIBE CAR-ENG  First name Last name
or for the Czech version
         SUBSCRIBE CAR-CS First name Last name

Peter Mellor, Centre for Software Reliability, City University, Northampton
Square, London EC1V 0HB, UK. +44 (171) 477-8422, p.mellor@csr.city.ac.uk


Unsolved Mysteries covers identity theft!

"Denis Parslow" <dgp@world.std.com>
Mon, 18 Aug 1997 12:41:55 +0000
Unsolved Mysteries, a TV show one step above Cops, had a recent piece
dedicated to a case of Theft of Identity.  A woman in Florida was receiving
credit card charges that she could not have made, and the situation
escalated to a condo lease, etc., upwards of $20,000.  The other woman (in
Cal) had gotten the birth certificate, had gotten a copy of a drivers
license, made a forgery with her own picture, proceeded to use these as
proof of ID for a Social Security card, and so on.

The Risks are already known [e.g., RISKS-19.05], but perhaps the typical
consumer may be becoming more aware of them.

Denis Parslow, Engineering Mgr, Almo Distributing, Trademark Computers
dgp@world.std.com  http://www.almo.com  http://world.std.com/~dgp/


The Door Is Open!

Glen Roberts <glr@ripco.com>
16 Aug 1997 16:04:42 GMT
I was going to post a nice story about the risks of travelling around San
Francisco with the Moderator of this group [*], but upon my return to
Cleveland, I found a much more significant risk!

I almost stayed at the Quality Inn in Brook Park, Ohio (we'll see what it
takes to get a full refund on the unused room). In addition to numerous
other problems...

The rooms used a mag-stripe card as a key. (As do most hotels these
days). Apparently to provide "better" security. If a key is lost or stolen,
it can simply be deactivated.

This Quality Inn, apparently has a major problem with keys being deactivated
for other reasons. While standing at the counter for less than 5 minutes, I
saw three people appear at the counter and state "my key doesn't work!" The
clerk: "What room number?"  their keys were then quickly reprogrammed for
that room number -- without any verification that it was actually their room
the key was being set for! An open door... anyone with keycard could get
entry to any room -- no questions asked!

Glen L. Roberts -- "political provocateur" -Newsday (3/30/97)
  The Stalker's Home page: http://www.glr.com/stalk.html

  [* Note: We taped a forthcoming CNET soundbite show.
  Check out Glen's website for ways in which you can be stalked.  PGN]


Insurance company billing error

<Paul_Green@vos.stratus.com>
Fri, 15 Aug 97 13:42 edt
I offer the following story as an ordinary consumer.  But as a professional
software engineer, I'm disappointed at what it says about the state of our
profession and how we facilitate insensitivity by our companies towards our
customers.

I have six insurance policies with Liberty Mutual.  For several years I have
been paying nearly all of my bills, including the five of the six separate
bills for the policies, electronically with CheckFree.  (My wife pays one of
them conventionally).  A year ago I bought a new car, and due to various
factors, ended up with a new policy instead of a roll-over of the policy for
the old car.  I'm very careful to use separate CheckFree merchant names for
each policy, so that each payment carries along the correct policy number.

A few weeks ago I sent in my renewal, in full, for another year of coverage.
Didn't have to set up the merchant account again; CheckFree remembered it
from last year.  Nice.  Imagine my surprise when I got a stern, bulk-mailed,
computer-generated letter saying that my policy would be cancelled if I
didn't quickly pay my bill.  Then, what seemed like just a few days later, I
got another bulk-mailed, computer-generated letter full of lawyerly phrases
informing me that my policy had been cancelled effective a week or so in the
future.

This type of payment problem happens to me several times a year with
CheckFree, and I must say, it has never been their fault, or the fault of my
bank.  It is invariably the fault of the merchant.  The drill is to see if I
paid the bill (yes), then see if the check has cleared my bank account (it
had).  Then see if the account number on the digitized image of the check on
the bank statement (in absolutely tiny print!) agrees with the merchant's
account number.  Then, call the merchant.

A magnifying glass revealed that CheckFree and I agreed on the account
number.  A second look at this year's bill, however, revealed that my
insurance company had quietly changed the account number, by a single digit,
when they renewed the bill.  (They often change the last couple of digits;
and they know to ignore these because they are a renewal sequence number.
This time they changed a high-order digit.  They've never done this before,
for any of my policies).

Where did my $847 go?  That's right, they applied my payment to last year's
account number.  The fact that I had already paid off that bill, that they
hadn't invoiced me for that account, that they had renumbered the account,
etc., apparently didn't register.  Nor did they produce an exception report
for paying a paid account (unless you consider a cancellation notice on the
renewal the exception report).

The humans at the insurance company eventually found and transferred the
misdirected payment, and I got another bulk-mailed, computer-generated
letter stating that my insurance would not be cancelled after all.  But no
apology.  (Perhaps they were waiting for me to apologize first for
misleading them?)  The lack of any apology really bothers me.

As I mentioned, I have six insurance policies with this company.  They add
up to quite a bill.  It is quite clear to me that I am not treated like a
single customer; I am treated like six customers (one of whom is now
presumably labelled a deadbeat).  I would like to receive a telephone call
or a personal, first-class letter when problems like this crop up.  I guess
that's too much to ask these days.  Grumble.

I only wonder what would have happened if I had been travelling, not known
of the problem, and had an accident while my policy was officially
cancelled.  Would I have ended up in court over whether or not I had paid
them?  Glad that didn't happen, but no credit to the insurance company that
it didn't.

Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Marlboro,
MA 01752   Paul_Green@stratus.com   +1 508-460-2557   FAX: +1 508-460-0397


Re: Ctrl-Alt-Del (Floyd, RISKS-19.29)

Li Gong <gong@games.Eng.Sun.COM>
Mon, 11 Aug 1997 15:09:18 -0700
> .. so you know that when you press that and get a login window, you're
> actually getting a Windows NT login window and not a window from a
> Trojan horse application.

Do you really know?  You can be sure of this security guarantee only if:
(1) the keyboard and the wires are not replaced or tampered with, and
(2) the resident DOS has not been modified, and
(3) the NT is authentic, and
(4) you are looking at the correct monitor, and
(5) the monitor is displaying real image (as opposed to a cartoon), and
(6) the keys have not been remapped, and
(7) ...

Li Gong, JavaSoft, Sun Microsystems Inc.


Re: Ctrl-Alt-Del (RISKS-19.28)

Morris Maynard <morrism@virtulink.com>
Wed, 13 Aug 1997 11:37:37 -0400
Who invented the Ctrl-Alt-Del "protocol"?  "Word as your email editor"
(Wordmail) is an *Option* with Exchange; clear instructions for disabling
this option are given by the install program for Exchange. And if you do not
have Word, Exchange will not enable Wordmail by default. For some reason
people seem to like to vilify Microsoft whenever they introduce a really
useful feature. Change can be good.

Wordmail is an example of the extensibility of Exchange; actually
anybody can build an editor and hook it into Exchange as an Email editor
using MAPI.

  [Tons of other messages on this subject.  Lots of duplication.
  Far too many to include.  PGN]

Please report problems with the web pages to the maintainer

Top