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 20 Issue 46

Saturday 19 June 1999

Contents

o NASA discloses space station blunder
SigmaXi ScienceInTheNews
o Y2K test sends sewage flowing in Los Angeles
Henry Baker
o Resetting the A320 computer
Diomidis Spinellis
o Intuit/Quicken Force Users to Internet & MS Internet Explorer
Lauren Weinstein
o MS Word not as helpful as it thinks
Bill Shymanski
o YANTBOF: yet another NT buffer overrun flaw
Epstein Jeremy
o New ATM hazard
Aahz Maruch
o Yet another ATM scam
Mike Williams
o The cell phone that wouldn't stay OFF
Michael Heilman
o Another case of credit-card 'security'
David Alexander
o Maldesigned computer system slows background checks
Kragen Sitaker
o Factoid paranoia
Mike Giroux
o Risks of keywords in CSV files
Rex Black
o REVIEW: "Intrusion Detection", Edward G. Amoroso
Rob Slade
o Info on RISKS (comp.risks)

NASA discloses space station blunder

inthenews <inthenews@SIGMAXI.ORG>
Fri, 18 Jun 1999 11:39:49 -0400
A blunder by flight controllers prevented the new international space
station from moving out of the way of dangerous space junk. The rocket
debris ended up passing at a safe distance.  NASA said the sequence of
computer commands sent up by flight controllers to fire the station's
engines over the weekend failed because of human error.  It disclosed the
incident Thursday.

Initially, the U.S. military organization that tracks objects in space
predicted the rocket chunk would pass within two-thirds of a mile of the
space station on Sunday. It ended up coming no closer than 4 1/2 miles.
http://www.latimes.com/HOME/NEWS/WIRES/WHEALTH/tCB00V0366.html
[*The Los Angeles Times, 18 Jun 1999*; From SCIENCE-IN-THE-NEWS]

Sigma Xi Homepage  http://www.sigmaxi.org
Media Resource Service  http://www.mediaresource.org
American Scientist magazine  http://www.sigmaxi.org/amsci/amsci.html


Y2K test sends sewage flowing in Los Angeles

Henry Baker <hbaker@netcom.com>
Fri, 18 Jun 1999 06:45:45 -0700
A supposedly routine test of LA's Y2K readiness of the emergency
preparedness system at the San Fernando Valley sanitation plant caused about
4 million gallons of raw sewage to be dumped into the Sepulveda Dam area.  A
gate to a major sewer pipe closed without warning because of a programming
error.  [Source: article by Miguel Bustillo, Karima A. Haynes, Patrick
Mcgreevy, http://www.latimes.com/HOME/NEWS/FRONT/t000054865.html,
*L.A. Times*, 18 Jun 1999; PGN-ed]


Resetting the A320 computer

Diomidis Spinellis <dspin@aegean.gr>
Sat, 19 Jun 1999 03:05:01 +0300
I was travelling from Athens to Munich on Lufthansa flight LH 3425 on 16 Jun
1999.  Shortly before taxiing for takeoff, our A320 plane left the runway
and moved aside.  The captain immediately informed us that we were having a
slight technical problem that they would try to rectify and that we would be
given further information in a short while.  About five minutes later the
following announcement was made:

  "Ladies and Gentlemen this is your captain again.  We had to reset two
  of our computers and now it is looking real fine again."

During the flight the crew kindly allowed me to talk to the first officer
about the incident.  My prepared list of questions concerned the problem
domain, its criticality, frequency of occurrence, and reporting procedures.
According to the captain, the problem occurred on a flight control computer
(ELAC1) and involved erroneous position monitoring of the right elevator.
The officer assured me that the problem was not critical, occurred on only
one of four different reports and although it was part of a ground checklist
it would not have been a problem during the flight.  I was told that such
problems sometimes do occur and that the problem had already been reported
by telex to the airline's maintenance base.

Here is a verbatim - I hope - transcription from a printed log I was shown:

  F/CTL servo fault
  R Elevator POS MON XDLR

(Disclaimer: I am not an aviation expert; the report is my - perhaps
limited - understanding of the captain's answers.)

The risks?  As far as I know modern flight-control computers do not need a
reset before takeoff*, nor should a reset be needed after a human operator
error.  Obviously a software or hardware fault had caused the computers to
malfunction.  Since resetting a computer does not typically isolate and
correct faults (otherwise Windows would long have reached a 0% defect rate),
we were flying on a plane with a known and demonstrated software fault.
Although the problem manifestation was on a non-critical area, we all know
that the underlying cause could well result in more serious side-effects
since it occurred on a critical flight control component.  More worryingly,
this appeared not to be a singular event.

[*] Interestingly the Space Shuttle software does need to be reloaded
between different flight phases.  A fascinating description can be found in
Gene D. Carlow. Architecture of the space shuttle primary avionics software
system. Communications of the ACM, 27(9):926-936, September 1984.

Diomidis Spinellis, University of the Aegean


Intuit/Quicken Force Users to Internet & MS Internet Explorer

Lauren Weinstein in PRIVACY Forum <privacy@vortex.com>
Sat, 19 Jun 99 12:22 PDT
PRIVACY Forum Digest      Saturday, 19 Jun 1999      Volume 08 : Issue 09

Moderated by Lauren Weinstein (lauren@vortex.com)
Vortex Technology, Woodland Hills, CA, U.S.A.   http://www.vortex.com

Date:    Sat, 19 Jun 99 09:46 PDT
From:    lauren@vortex.com (Lauren Weinstein; PRIVACY Forum Moderator)
Subject: Intuit/Quicken Force Users to Internet & MS Internet Explorer

Greetings.  Just as the banking industry in the U.S. has been issuing
concerns about the security of Internet and Web-based banking systems, one
of the biggest players in the online banking industry, Intuit, makers of
Quicken, have quietly moved to force all of their users onto the Internet
for all online banking services, and in some cases are requiring the
use of Microsoft's Internet Explorer instead of other browsers such
as Netscape Navigator.

Catherine Allen, chief executive of the Banking Industry Technology
Secretariat, a division of Bankers Roundtable, recently said, "The banks
feel that firewalls and what they have internally is in great shape, but the
link is to the consumer and PC environments [where they find security more
suspect]."

While newer versions of Quicken software have apparently been Internet-based
for some time, many users had opted to stay with older versions since they
used direct dialup lines for communications, and did not rely on Microsoft's
Internet Explorer.

However, Intuit (and/or in some cases users' banks) over the last two months
or so have been sending out a somewhat confusing series of letters, informing
these users that their versions of Quicken are not "Y2K" compliant, and that
they must upgrade by designated nearby dates (e.g. June 30, 1999) or lose
their online banking access.  Some materials simply suggested that certain
features (such as pre-scheduled bill payments) would have problems past
Jan 1 2000--other materials claimed a total cutoff of services to
non-upgraded users.  Sometimes the same letter seemed to make
both statements.

Intuit and/or user banks made a number of options available, including a
free minimalist downloadable upgrade and various payment-based enhanced
upgrades.  However, the fine print of these offers (sometimes buried at the
end of the letters) indicated that all access would be via the Internet for
these new versions.  Arrangements for limited free Internet access would be
available to those who didn't already have an Internet Service Provider, the
letters suggested.

I spent a couple of weeks clarifying this whole situation with Intuit and
their public relations firm through a lengthy series of phone calls.  While
it wasn't difficult reaching Intuit's public relations folks, getting to
people who could answer technical questions at this level was a bit more of
an effort.  However, everyone involved was polite and willing to address my
questions in a direct manner to the extent that they could.

The bottom line is that all users of older Quicken software *do* need to
upgrade and *will* be using the Internet for all future transactions.  There
will be limited free Internet access available for Quicken transactional use
(I believe an hour a month, which would be sufficient for this purpose) for
people who need the service.  It is a bit unclear how long this free access
would be available--one person suggested indefinitely, but this does not
appear to be a guarantee.

I'm told that existing users doing the minimalist upgrade from older Quicken
versions (e.g. Version 5 for Windows) will not need to install or use
Internet Explorer (IE) for most online operations.  Users of the more
sophisticated upgrades may be required to use IE for more functions, and
*all* new users of Quicken will be required to install and use IE for secure
signup--Intuit claims that Netscape doesn't have the "required"
functionality for this purpose.

I'm also told that the "standard" installation option of many or all of
these new Quicken versions will install IE by default.  This means that if
you do not want an IE installation (and if you're in a category of existing
user that doesn't need it) you would probably have to disable the IE
installation via the "custom" installation options of the Quicken setup
program.  This could be particularly important to users who may be concerned
about losing existing associations and defaults for any other web browser
already installed (which may be affected by an IE installation), or where
security concerns over IE's ActiveX functions and other related system
complexities are present.

I have in the past expressed other concerns with Quicken.  A continuing
problem is that if online banking transactions are not downloaded at frequent
enough (unannounced) intervals, transactions will be silently lost and all
related calculations and records from that point onward will be in error
unless manually corrected.  Intuit's response to this issue continues to be
suggesting that users have paper records to fix such problems, and that most
users access their data frequently enough that it isn't an issue for them.
Frankly, I would argue that this rather negates much of the point of using
the software in the first place, if you can't trust the transaction
record, even if relatively few people might be affected by this particular
undocumented problem!  I did by the way again suggest (this time to a
Quicken product manager) that users at *least* be warned when transactions
have been lost--they again said they'd consider it...

So, if you're a Quicken user, and you've recently been told you need to
upgrade due to that mean old Y2K monster, you're not alone if the situation
seemed a bit confusing based on the materials you received in the mail.

PRIVACY Forum Digest V08 #09, Lauren Weinstein --- http://www.vortex.com
Host, "Vortex Daily Reality Report & Unreality Trivia Quiz"
--- http://www.vortex.com/reality


MS Word not as helpful as it thinks

Bill Shymanski <wtshyman@mb.sympatico.ca>
Sat, 19 Jun 1999 13:33:09 -0400
I recently helped edit a specification, in which a list of items to be
supplied had the wrong quantities shown. It turns out Microsoft Word 97
though that the list beginning "1 Rack", and continuing on from there, was
supposed to be a numbered list - so Word "helpfully" automatically
incremented what was meant to be the quantity field as if it were sequence
numbers of a list.  Luckily this was caught at draft stages, but the risk of
getting quantities wrong is present.

On the whole, I find that features of this nature cost more time than they
save; the software is never smart enough to figure out what I really want
and when it guesses, it usually gets it wrong. I'd sooner type my own
numbered lists than fight with the word-processor. Automatic renumbering is
also fairly useless if you happen to refer elsewhere in the document to,
say, item 3.4.5 and Word has renumbered it after the reference was created.

W. T. Shymanski <wtshyman@mb.sympatico.ca>


YANTBOF: yet another NT buffer overrun flaw

"Epstein, Jeremy" <Jeremy_Epstein@NAI.com>
Fri, 18 Jun 1999 06:53:49 -0700
Just in case anyone hasn't seen it already:
  http://www.eeye.com/database/advisories/ad06081999/ad06081999.html
for the technical info, or
  http://www.wired.com/news/news/technology/story/20285.html
for a higher-level description.

This was also mentioned briefly in *The Washington Post*, 18 June 1999.

--Jeremy

  [And Microsoft is accusing eEye of unfairly releasing information on
  this flaw, whereas eEye is claiming they notified MS -- which did not
  fix it rapidly enough.  The obvious comment must be
    Old McRosoft had affirm:
    eEye, eEye, Owe!
  See http://www.excite.com/computers_and_internet/tech_news/zdnet/
    ?article=/news/19990617/2277295.inp
  PGN]


New ATM hazard

Aahz Maruch <aahz@netcom.com>
Thu, 17 Jun 1999 09:30:08 -0700 (PDT)
UTM Systems (http://www.utmsystems.com/) is offering a new ATM card
reader that goes into the floppy drive of a PC.  I wonder how easy it'll
be to crack the system to collect passwords -- they're advertising it
for use in point-of-sale systems.


Yet another ATM scam

"Mike Williams" <mikew@harlequin.co.uk>
Wed, 16 Jun 1999 11:13:05 +0100
There was report in the Preston Citizen (Lancs. UK) last week about a new
ATM scam.  This has taken place at ATMs at large supermarkets.  Basically,
'devices' have been added to the exterior to get the pin number and read the
card's magnetic strip -

'One device is an invisible key pad which is placed over the existing keys,
which records the pin number, while another invention placed over the card
slot copies the data on a magnetic strip. ... Because the user gets the card
back and the cash requested they believe nothing is wrong. ... Police fear
hundreds of local people have been affected by the scam. ... "We have talked
to around 200 victims locally, most of who have been losing varying amounts
in 250UKP sums."'

The bank has reportedly put a warning on its ATMs (I don't use there ATMs)
warning customers to be on the lookout, and advises customers that if
'... they see anything suspicious on a machine they should not use it.'

It seems supermarket ATMs were targeted since the crooks can easily keep an
eye on them from the car park, plus have unobserved access to them at night
- the supermarkets are usually on the edges of towns with minimal lighting.

No need to point out the risks ...


The cell phone that wouldn't stay OFF

<Michael_Heilman@infoimage.com>
Thu, 17 Jun 1999 13:06:08 -0400
My wife and I received a very long, very unusual message on our answering
machine one day. Under a complex layer of foreground noises, there was a
discernible conversation being recorded. After listening to it several times
and recognizing personally significant phrases, we were quite concerned. It
took several puzzling hours to realize what had happened: my wife had
slipped her cell phone into her purse and as we were walking down the
street, something pressed against the re-dial and called our home phone. Our
answering machine recorded our muffled conversation under a layer of noises
from the phone rubbing and jostling.

The RISK became apparent a couple of week later when my wife received a call
from a business colleague asking if she had just called him back after their
conversation, because he had just overheard the strangest sounding phone
call.  Well, what he heard, by the same mechanism, was my wife discussing,
with someone else, her previous conversation with him right after hanging up
and putting her phone away. Luckily, she had had nothing derogatory or
confidential to say!

Looking for a solution: the phone has a keyboard lock that requires pressing
1-2-3 to unlock ... pretty good, but not foolproof. If the phone is turned
off, it is very easy for it to get turned back on--just a quick press of one
button.


Another case of credit-card 'security'

David Alexander <dave_ale@online.rednet.co.uk>
Wed, 16 Jun 1999 10:19:53 +0100
Yesterday I telephoned my credit card company to make some enquiries about
various options they were offering. It was the first time I had called them
for at least a year. Imagine my surprise when I was first asked to enter my
credit card number in full and then informed that 'in order to improve
security I needed to decide on a 4 digit number to be used to verify who I
was in future'. I was then asked for my date of birth and the expiry date on
my card as proof of who I was before being allowed to give them a number.

Hopefully the alarm bells have already gone off in your heads like they went
off in mine. The whole idea is so full of holes and risk. Anyone who has
accepted my card will have the full number and expiry date. Here in the UK
you can get a copy of a Birth certificate with minimal difficulty, so anyone
could ring up purporting to be me and 'swipe my identity' [pun intended]. I
haven't sat and thought through in detail exactly what scams they could then
pull off by telephone in terms of obtaining items by deception or simply
wrecking my relationship with the company.

Be careful what you do on the phone.

David Alexander, Camberley, England, Founder member, European Top Methanol
Racers Association http://home.rednet.co.uk/homepages/dave_ale/dave_ale.html


Maldesigned computer system slows background checks

Kragen Sitaker <kragen@pobox.com>
Tue, 15 Jun 1999 17:23:26 -0400 (EDT)
I expected to see this in the latest RISKS.  It appeared in USA Today
on 1999-06-03, page 1A and 2A, in an article entitled, "Pentagon
crisis: Security-check backlog."  Amid discussion of various kinds of
mismanagement, agency politics, and the effects of the backlog (capsule
summary: people like me who have security clearances get them by
filling out some forms and then having Defense Security Service people
chat with everyone they've known for the last ten years, and the
process takes way too long), there was this juicy tidbit:

  That flap was nothing compared to the problems that have emerged in the
  past eight months, since the security service turned on its new computer
  system at its Baltimore operations center.  The Case Control Management
  System, or CCMS, [outgoing DSS director Steven] Schanzer says, was
  designed to "automate the management of the investigative process."  But,
  say DSS officials, the system isn't working and there is no backup
  operation in place.  [It's not clear whether they decommissioned an older
  computer system without thorough testing of a new one, or whether they
  just didn't have an older computer system that did the things this one
  does.]

  Last April, the computer system crashed for four days, meaning ...  "no
  internal or external customers could get information from the system."

  Schanzer says the problem is simple: the system choked on paper.  It was
  designed to take electronic questionnaires from security applicants, but
  it was deluged with tens of thousands of paper submissions.

  Another problem: The agency assumed applicants would fill out the forms
  correctly.  In many cases, that hasn't happened, and the system can't
  detect the errors, Schanzer says.  [Is this connected to forms being
  filled out by hand instead of via EPSQ, which won't allow submission of
  forms with certain kinds of errors?  Or is this a separate problem?  Is
  this related to the crash?]

  There is yet a third problem.  Schanzer says the agency now has figured
  how to get the paper through the system, but once a case is completed, it
  takes about 20 days to get a print-out.  [What?  Why?  No clues here.]
  ... "It should take no time at all," he explains.  [...]

  "We are bringing on an independent team to assess where we are with the
  computer system," he [John Hamre, deputy Secretary of Defense] says.  "I
  need to know if we are barking up an empty tree" with the existing system,
  or whether it should be replaced.

Earlier parts of the article explain that many, many people are getting paid
to sit around and do nothing until their clearances are granted (or denied,
in which case they are fired), and that soon, some classified contracts will
cease to progress until clearances are granted, and that the NSA has
recently gotten an exemption from the Pentagon to hire PIs to do the NSA's
background checks, instead of relying on DSS.

The RISKS are not clear here, due to (what appears to be) USA Today's usual
shoddy reporting.  It sounds like the usual problem of undue reliance on
untested software that was designed without reference to real life.

<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>


Factoid paranoia

Mike Giroux <rmgiroux@hotmail.com>
Tue, 15 Jun 1999 05:25:14 PDT
An interesting research project is described at

http://www.research.digital.com/wrl/projects/Factoid/index.html

Basically, this is a device that would log all of the small "factoids" that
a person passes by each day (broadcast by other factoid devices in
billboards or business cards, for instance), and then upload them into a
home database in a secure way at any opportunity.

This system is only in the theoretical stages, so this isn't an urgent
problem.  However, my worry about the factoid system is about the
"subpeona-bility" of the home database.  Would you want a step-by-step
record of where you went and who you saw each day of your life available to
anyone who wants to start a nuisance civil suit against you?

Apart from that concern, though, it looks like a cool toy, and maybe even a
useful tool.  Maybe if "factoid privilege" were part of the law, this thing
could take off.

Mike


Risks of keywords in CSV files

Rex Black <rexblack@ix.netcom.com>
Tue, 15 Jun 1999 17:20:34 -0500
Here's a fun "file portability" bug that sucked up a couple hours of my day.

1. Create a comma-separated variable file with three or four variables.

2. Name the first column "ID".

3. Try to import the file into Excel 97.  You will receive a "Sylk: File
   format invalid" error.

4. Rename the first column "BugID".

5. Repeat step three.  No problem.

I'm guessing that the file import facilities use the word "ID", if it occurs
in the first two bytes of a file to be imported, as a keyword meaning, "The
next few bytes will tell you what type of file this is."  When the next few
bytes are just the headers for the rest of the columns, Excel pukes.

The Risk?  In my opinion, this is the old "laconic/cryptic error message"
risk.  Had the error message said, "Keyword 'ID' followed by invalid type,"
I would have gotten it right away.  Instead, I went off on a wild goose
chase involving fix-width columns, tab-separated columns, and the like,
before I tried twizzling the header and--behold!--it worked.

Rex Black Consulting Services, Inc., 7310 Beartrap Lane, San Antonio,
TX 78249  +1 210 696 6835  http://www.RexBlackConsulting.com


REVIEW: "Intrusion Detection", Edward G. Amoroso

Rob Slade <rslade@sprint.ca>
Thu, 17 Jun 1999 08:43:56 -0800
BKINTDET.RVW   990423

"Intrusion Detection", Edward G. Amoroso, 1999, 0-9666700-7-8, U$49.95
%A   Edward G. Amoroso eamoroso@mail.att.net
%C   P. O. Box 78, Sparta, NJ   07871
%D   1999
%G   0-9666700-7-8
%I   Intrusion.Net Books
%O   U$49.95 973-448-1866 fax: 973-448-1868 order@intrusion.net
%P   218 p.
%T   "Intrusion Detection"

This is not (very much not) to be confused with the identically named, and
almost equally recent, book by Escamilla (cf. BKINTRDT.RVW).  Where
Escamilla's is basically a large brochure for various commercial systems,
Amoroso has specifically chosen to avoid products, concentrating on
concepts, and not a few technical details.  The text is based on material
for an advanced course in intrusion detection, but is intended for
administrators and system designers with a security job to do.

Chapter one, after demonstrating that the term means different things to
different people, gives us an excellent, practical, real world definition of
intrusion detection.  This is used as the basis for an examination of
essential components and issues to be dealt with as the book proceeds.  Five
different processes for detecting intrusions are discussed in chapter two.
Each method spawns a number of "case studies," which, for Amoroso, means
looking at how specific tools can be used.  (This style is far more useful
than the normal business case studies that are long on who did what and very
short on how.)  Intrusion detection architecture is reviewed in chapter
three, enlarging the conceptual model to produce an overall system.  Chapter
four defines intrusions in a way that may seem strange, until you realize
that it is a very functional description for building detection rules.  The
problem of determining identity on a TCP/IP internetwork is discussed in
chapter five, but while the topic is relevant to intrusion detection, few
answers are presented.  Correlating events is examined in chapter six.
Chapter seven looks at setting traps, primarily from and information
gathering perspective.  The book ends with a look at response in chapter
eight.

The bibliography is, for once, annotated.  While I do not always agree with
Amoroso's assessments; I think he tends to give the benefit of the doubt to
some who primarily deliver sensation; the materials are generally high
quality resources from the field.  Books and online texts are included,
although the emphasis is on journal articles and conference papers.

The content is readable and, although it seems odd to use the word in
relation to a security work, even fun.  I suppose, though, that I must point
out that your humble "worst copy editor in the entire world" reviewer found
a significant number of typographic errors.  (And some that can't be put
down to typos: I think you'll find that it's "berferd" rather than
"berford.")

This book works on a great many levels.  It provides an overall framework
for thinking about security.  It thoroughly explains the concepts behind
intrusion detection.  And it gives you some very practical and useful advice
for system protection for a variety of operating systems and using a number
of tools.  I can recommend this to anyone interested in security, with the
only proviso being that you are going to get the most out of it if you are,
indeed, responsible for designing network protection.

copyright Robert M. Slade, 1999   BKINTDET.RVW   990423
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top