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 16

Friday 15 January 1999

Contents

o Another premature data release
PGN
o NSA says Furby is a national security risk
Bruce Martin
o Man crashes car as 50 pagers ring simultaneously
Geoffrey Leeming
o 16-yr-old Irish girl's crypto system
PGN
o Over-reliance on technology
Pat Place
o The risks of a first failure
Bertrand Meyer
o If at first you don't succeed, breaking-in's no crime in Norway
Edupage
o Viruses and Rocket Science
Henry Spencer via Tom Evans
o Smurf denial-of-service attack on OZEMAIL
Mich Kabay
o Y2K in Swiss hospitals
Debora Weber-Wulff
o 1 Apr 2001 flaw in Windows
PGN
o Quicken 1999 bug
James S. Vera
o A good Y2K bug
Lenny Foner
o Utilities and Y2K: not to worry
Ken Knowlton
o Y2K testing tools
Craig Raskin
o Java Security
Gary McGraw
o REVIEW: "Maximum Security", Anonymous
Rob Slade
o REVIEW: "Year 2000 in a Nutshell", Norman Shakespeare
Rob Slade
o Info on RISKS (comp.risks)

Another premature data release

"Peter G. Neumann" <Neumann@csl.sri.com>
Tue, 13 Jan 1999 08:12:17 -0800 PST

The Department of Labor Statistics has once again accidentally released data
a day early, this time with the Producer Price Index.  Whereas last time
(RISKS-20.05) it was "a human failure", this time it was attributed to a
``software programming error''.  As usual, the problem has been corrected,
and won't happen again.  [Source: *San Francisco Chronicle*, 13 Jan 1999,
front page of the business section, PGN Abstr.]


NSA says Furby is a national security risk

<Bruce_Martin@manulife.com>
Wed, 13 Jan 1999 13:15:00 -0500

On 13 Jan 1999, CNews (www.canoe.ca) carried the AP news story about a U.S.
national security risk posed by the stuffed toy sold under the name of
Furby.  For the uninitiated, Furby was the hottest-selling toy of the Xmas
'98 season.  Resembling furry gremlins [and apparently being sued therefor],
Furbies are bristling with audio, infrared, and touch sensors, allowing them
to interact with people and with others of their kind.

Detailed information on the capabilities (intended or not) of the average
Furby can be found at: www.homestead.com/hackfurby. Among their repertoire
of tricks, these toys have the apparent ability to mimic human speech in
parrot-like fashion, and therein lies the risk.

According to no lesser authority than the National Security Agency, these
toys were being brought into top-secret areas at Fort Meade by government
employees, where the little devils (the toys, not the employees) could
easily be exposed to classified information which they might later repeat
to foreign agents.

Furby is now "machina non grata" at Fort Meade, and transgressors are to
report to their Staff Security Office for guidance on this matter. A Capitol
Hill source is quoted in the Washington Post of 13 Jan 1999 as saying they
feared "that people would take them home and they'd start talking
classified."

The risk of U.S. national security resting in the hands of adults who play
with children's toys during office hours is left as an exercise to the
reader.

Bruce Martin, Toronto

  [The manufacturer insists that the memory cannot be altered, and
  that the furbies cannot learn from their environments.  However,
  because Furbies are programmed to react to responses, there is always the
  question of whether there might be a preprogrammed Trojan horse recording
  their choices, and providing a nifty covert channel.  Until recently, if
  you brought viewgraph transparencies into the agency to give a talk, it
  was nontrivial to get them out again -- because they were photographic
  media.  Presumably, similar thinking goes into NSA's Furby policy.  PGN]


Man crashes car as 50 pagers ring simultaneously

<geoffrey.leeming@henderson.com>
Fri, 15 Jan 1999 11:27:39 -0100

A man in the Ukraine bought 50 pagers as presents for his staff.  While
driving home, they all rang at the same time.  He was so distracted that he
crashed into a lamp post, within 100 meters of his office.  Of course,
each one said simply, ``Congratulations on a successful purchase!''
[Source: Yahoo News via Reuters, 15 Jan 1999; PGN Abstr.]


16-yr-old Irish girl's crypto system

"Peter G. Neumann" <Neumann@csl.sri.com>
Wed, 13 Jan 1999 08:20:21 -0800 PST

Sarah Flannery, 16, in Blarney, County Cork, Ireland, has designed a crypto
system (called Cayley-Purser).  ``She is considering publishing her findings
rather than patenting as she does not want people to pay for her
discovery.''  Source: Audrey Magee, *The Times*, London, 13 Jan 1999;
Edupage, 14 January 1999, PGN Stark Abstr.  TNX to Lindsay Marshall]

  According to some technical discussions on the net, the scheme is based on
  2x2 matrices, and appears to be 10 times faster than RSA, but with much
  longer keys, and apparently with security comparable to RSA for comparable
  modulus sizes.

    I'm not sure from the articles I've seen whether the reporters are
    more surprised by Sarah's age or her gender.  But there seems to be
    general astonishment that she could come up with a crypto algorithm.  On
    the other hand, RISKS readers know that lots of people have come up with
    crypto algorithms.  If this one is really good, that *is* special.
    That she wants to keep it open is even more special.  PGN


Over-reliance on technology

Pat Place <prp@SEI.CMU.EDU>
Tue, 12 Jan 1999 09:07:19 -0500

In answer to Jordin Kare's TROFF problems (RISKS-20.14), Glen Turner
(RISKS-20.15) suggests the use of a text editor displying different
syntactic components using different textual properties (colour, font, and
size being the common variables).

I'm sure that XEmacs and other editors of that sort do their best, however,
with a language such as TROFF, where everything can be changed including the
escape character and the control line characters (.ec, .cc, and .c2), unless
the editor contains a TROFF interpreter sooner or later it will be confused.

Although, XEmacs' best attempt may be good - we shouldn't rely on it
for accuracy - the best solutions to Jordin Kare's problems are
  1) understand the tool you are using (the nroff/troff user manual is
     invaluable here)
  2) proof-read carefully everything you produce.

Pat Place prp@sei.cmu.edu


The risks of a first failure

<Bertrand.Meyer@eiffel.com>
Wed, 13 Jan 99 11:14:53 PST

A cute little bug on http://www.dejanews.com (but please don't try this
except possibly on a test group):

  Successfully post an article through DejaNews (after registering as a user)
  You get an article number <nnnn> to be used if you want to cancel
  Change your mind (L'uomo e` mobile)
  Go to the cancellation page, include nnnn as the article number
  (You are not only fickle but careless, and didn't notice
        that you are supposed to put in the angle brackets too.)
  It finds your article
  Confirm cancellation by clicking the appropriate button
  You get a message stating that this is not a valid article number
  Realize your mistake (the forgotten angle brackets)
  Try cancellation again, this time including the brackets
  It finds your article
  Confirm cancellation
  You get a message to the effect that this article appears to have been
        cancelled already!

As far as I know there is no way after that to cancel the article
(but I haven't contacted Dejanews about it).

The reason I mention this small apparent bug is that it is representative of
an interactive system risk that one encounters all too frequently. It arises
for a kind of "transaction", in the broad sense of the term, that a system
accepts to carry out at most once. If, however, an attempt fails and is
rejected by the system, it may have been registered in the same way as a
successful attempt, so that later on the system may believe that the
transaction has already taken place, and reject any further attempt,
resulting for the user in a Catch-22 situation.

The more general design principle is: if you reject an operation after it
may already have affected the information in your system, make sure that the
rejection process brings the information back to a consistent state.

  (I am not writing: "... that it restores the information to its original
  state", because that may be impossible; even if possible it may be
  undesirable, e.g. we may want to keep a record of failed attempts.  What we
  don't want is partial success leading to an inconsistent database.
  Obviously the use of invariants and other Design by Contract principles
  helps in defining and enforcing "consistent" states.)

People designing transaction processing systems in the strict, conventional
sense are well aware of the risk and the principle, but I think we would all
benefit if it were known and applied much more broadly.

Bertrand Meyer, Interactive Software Engineering, Santa Barbara
<Bertrand.Meyer@eiffel.com>, http://eiffel.com


If at first you don't succeed, breaking-in's no crime in Norway

Edupage Editors <edupage@franklin.oit.unc.edu>
Thu, 14 Jan 1999 11:52:05 -0500

The Supreme Court in Norway has ruled that it's not a crime to try to break
into someone else's computer system, because people should expect others to
try to invade their systems, and take measures to protect themselves.  There
is a crime, ruled the court, only if the system is actually breached.  The
case developed out of an attempt by a computer security company to break
into the University of Oslo's computers through the Internet, to contribute
to a feature story by the Norwegian state broadcasting network.  Apparently
the security company mapped holes in the university's computer security, but
did not break in, tamper with, or steal any information.  (*USA Today*,
13 Jan 1999; Edupage, 14 January 1999)


Viruses and Rocket Science

Tom Evans <TEvans@tennyson.com.au>
Fri, 15 Jan 1999 19:03:18 +1100

The following is lifted directly from Henry Spencer's summary of AW&ST
posted to sci.space.news:

Date:     1999/01/06
>From: Henry Spencer <henry@spsystems.net>
Subject:  space news from Nov 16 AW&ST

As if Sea Launch didn't have trouble enough, now its computers (as well as
those of some other Boeing projects) have come down with a massive virus
infection.  The viruses apparently spread via documents about Sea Launch
export compliance, which were widely distributed to staff in the wake of the
project's recent government problems.  Boeing had few defences in place, and
was slow to act because the viruses initially seemed harmless.

Full article available as:

http://x7.dejanews.com/getdoc.xp?AN=429551406.1&CONTEXT=916023969.559415504&
hitnum=1

Tom Evans <TEvans@tennyson.com.au>


Smurf denial-of-service attack on OZEMAIL

Mich Kabay <mkabay@compuserve.com>
Thu, 14 Jan 1999 09:47:48 -0500

According to an article by Tim Barlass in the Daily Telegraph of Australia
(12 Jan 1999, p. 9), someone has launched a sustained smurf
denial-of-service attack on Ozemail, an important Australian Internet
service provider.  E-mail service has been disrupted for users in Sydney.  A
company spokesperson said they were trying to track down the perpetrator and
were considering installing filtering software to prevent future attacks.

  [Note from MK: a "smurf" attack uses widely-available software written by
  criminal hackers to send ping packets with forged origination in the
  headers to a (usually major) corporate network's broadcast address.  Every
  device -- perhaps hundreds or thousands -- sends a reply packet to the
  forged originator address.  That system thus receives a flood of packets,
  often overloading its TCP/IP stacks and resulting in denial of service.
  See the article by Michael Dillon in ASK THE INFRA EXPERT (Internet World:
  Apr 20, 1998) for a more detailed explanation.]

M. E. Kabay, PhD, CISSP / Director of Education
ICSA, Inc. <http://www.icsa.net>


Y2K in Swiss hospitals

Debora Weber-Wulff <weberwu@tfh-berlin.de>
Thu, 14 Jan 1999 14:22:58 +0100

I heard about this from an informant, took quite some searching to find the
little notice hiding on the pages in the NZZ (Neue Zuercher Zeitung, 7 Jan
1999) usually reserved for reporting celebrity divorces, plane crashes and
natural disasters. An on-the-fly translation:

The hospitals in the canton de Vaud (Waadt) spent the 1st and 2nd of January
1999 fighting with the computer problems that are expected for the year
2000.  Except for the University Hospital in Lausanne, the computer systems
for admitting patients in all of the hospitals of the canton were down for
36 hours.  Specialists were able to fix the problem, according to a
spokeswomen for the hospitals in the newspaper "24 Heures" (24 hours) on
Wednesday.  The reason for the system crash is the fact that it was
programmed to compare something with the date a year in the future.  This
was programmed in 6 digits as "01.01.00".  The system interpreted this as 1
Jan 1900.  Source: Year-2000 computer problem in Waadtlaender hospitals
Lausanne, http://archiv.nzz.ch/books/nzzmonat/0/8466081T.html]

Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin
FB Informatik, 13353 Berlin, Germany  http://www.tfh-berlin.de/~weberwu/

  [Waadt's New?  PGN]
     [Canton Waadt is known elsewhere as Canton de Vaud.
     Correction inserted later in archive copy, suggested by Bertand Meyer,
     who also suggested an additional pun:
        "Vaud denn ist dieser Kanton?"
     Thanks!  PGN]


1 Apr 2001 flaw in Windows

"Peter G. Neumann" <Neumann@csl.sri.com>
Thu, 14 Jan 1999 18:12:12 -0800 PST

Windows (95,98,NT) systems apparently suffer from an off-by-one-week glitch
on the daylight savings time cutover in 2001, shifting on 1 Apr rather than
8 Apr.  An updated library program will solve the problem.  [Source: John
Markoff, *The New York Times*, 14 Jan 1999; PGN Abstr, via Dave Farber and
others.]


Quicken 1999 bug

"James S. Vera" <vera@anna.stanford.edu>
Tue, 12 Jan 1999 16:44:39 -0800

Another 1999 bug, Intuit's Quicken'99 fails with a "divide by zero"
message when a transaction dated in January 1999 is recorded in the Auto
category and its "Home and Car Center" is opened.  See
http://www.intuit.com/support/quicken/faqs/win2/1913.html

James S. Vera       |         Internet         | Voice: +1.415.725.0256
Stanford University |  vera@anna.stanford.edu  | FAX:   +1.415.725.7398


A good Y2K bug

Lenny Foner <foner@media.mit.edu>
Wed, 13 Jan 1999 01:59:00 -0500

> January 1, 2000
> Re:  Vacation Pay

> Dear Valued Employee:

> Our records indicate that you have not used any vacation time over the
> past 100 year(s).  As I'm sure you are aware, employees are granted 3
> weeks of paid leave per year or pay in lieu of time off.  One additional
> week is granted for every 5 years of service.

> Please either take 9,400 days off work or notify our office and your next
> pay cheque will reflect payment of $8,277,432.22 which will include all
> pay and interest for the past 1,200 months.

> Sincerely, Automated Payroll Processing


Utilities and Y2K: not to worry

Ken Knowlton <KCKnowlton@aol.com>
Mon, 11 Jan 1999 20:49:06 EST

I quote from a 10 Jan 1999 article in *The Boston Globe* on utilities' Y2K
readiness:

  Typical is one filing from Notheast Utilities: "NU has found nothing
  that cannot be repaired or replaced and be made Year 2000 ready in time,"
  it states.

They don't get it:  the devil is in the gotchas not found.


Y2K testing tools

Craig Raskin <raskin@compusec.org>
Wed, 13 Jan 1999 14:58:28 -0500 (EST)

I am currently involved with doing y2k testing at a client site. I have
spent numerous hours looking for tools which can be used for building test
suites. Unfortunately, I have not been able to find very many tools which
are worthwhile.

A lot of the available tools appear to have been built by individuals who do
not fully grasp the underlying concept of the machines and operating systems
which they are trying to test.

I have written some c code which should cause alerts with testing software
that checks for possible y2k problems. When compiled and checked under
microsoft based platforms, these binaries easily slip by testing
programs. When compiled and checked by Sun's own y2k testing tools, these
binaries also slip by.

Since Sun's tools are based on shell scripts, I was able to go in and find
the problem. The script works fine under the Sparc editions of the operating
system but returns false information when run under the Intel x86
version. This is due to the 'dump' command having differing output between
the OS versions. This slipped by the engineers at Sun.

Out of necessity, a lot of people are now doing system testing for the first
time in their careers. The risks are obvious. How many systems have been
checked and certified with buggy tools? Have individuals involved with
testing first checked that their test suites will actually work? Do they
even know how? We will find out soon enough.


Java Security

Gary McGraw <gem@rstcorp.com>
Wed, 13 Jan 1999 22:35:54 -0500 (EST)

Ed Felten and I are pleased to announce the publication of a completely
revised and expanded new book, a follow-on to our original 1996 book "Java
Security: Hostile Applets, Holes, and Antidotes" (better known as Java
Security HA HA among readers in the know).  The new book "Securing Java:
Getting down to business with mobile code" is published by John Wiley & Sons
(1999).  Physical copies are available now.  In addition to the physical
book, Ed and I decided to make the entire text available for free and
unlimited Web access.  The URL is:

http://www.securingjava.com

The risk here is that nobody will buy the physical edition ;-)!  Help
us mitigate that risk, making the Web experiment a success.  Ah
publishing in the 90s.

The book covers the risks presented by mobile code systems including
Java 2 and ActiveX  and is an in depth treatment of these complex issues.
RISKS readers will probably appreciate the tone.

Enjoy!

Dr. Gary McGraw, Vice President, Reliable Software Technologies
http://www.rstcorp.com


REVIEW: "Maximum Security", Anonymous

"Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
Mon, 11 Jan 1999 09:59:59 -0800

BKMAXSEC.RVW   981025

"Maximum Security", Anonymous, 1998, 0-672-31341-3,
U$49.99/C$70.95/UK#46.95
%A   Anonymous
%C   201 W. 103rd Street, Indianapolis, IN   46290
%D   1998
%E   Mark Taber newtech_mgr@sams.mcp.com
%G   0-672-31341-3
%I   Macmillan Computer Publishing (MCP)
%O   U$49.99/C$70.95/UK#46.95 800-858-7674 http://www.mcp.com
%P   829 p. + CD-ROM
%T   "Maximum Security, second edition"

Rather loudly promoted on the net these days, the major selling point of
this book is that it was written "by an experienced hacker."  Supposedly one
who spent some time as a guest of Uncle Sam for fiddling bank machines.
(Some of what we are told about the author does not fit with the contents of
the book, but then, as an old professional paranoid, I may be unduly
suspicious.)  Leaving aside questions of morality and definitions of the
term "hacker," let us merely observe that these people are the gnostics.
They are the devotees of the hidden, esoteric, and arcane knowledge.  Such
knowledge, of course, is cheapened and weakened by being revealed.  Which
may explain a certain reticence on a number of points in the first edition
of the book.  The introduction to that edition made it fairly clear:
Anonymous assumed that if you did not work diligently at his direction you
did not deserve to secure your system.  One could almost feel his glee at
the expectation that thousands of sysadmins around the world were wracking
their brains and flooding Usenet with discussions of the significance of his
clues to the vital encrypted message he had hidden on the CD-ROM.

The riddle, and that attitude, seem to have been removed from this second
edition.  The author tacitly admits that the first was a bit of a kludge: he
says that it was written in haste.  He also states that the second edition
is more "solution oriented."  It could hardly have been less.  Be that as it
may, the book is, as the author states, essentially completely rewritten.
It has been much improved in the process, moving up from truly awful to
merely mediocre.  The new version provides a good deal of reference
information, although assessing the quality of that information is left as
an exercise to the reader.

The section on viruses is an overview of the book in miniature.  The hype
has been toned down, and the explanation of how viruses work is much more
reasonable.  However, it still insists that "destruction" is the major
characteristic of a virus.  (There is, later, an admission that "[m]ost
viruses do not actually destroy data.")  We are treated to the old myth that
virus researchers write viruses as a kind of job security.  While a general
background to viruses is provided, there is no discussion of protection
options.  However, there are more listings of antiviral programs and
resource sites than there are for virus creation programs.  Many topics
within the text have lists of books and Web sites for further study, and
there is one for viruses that includes three of the four tomes recommended
by the VIRUS-L FAQ.  Unfortunately, it also contains some lesser works, and
there are no annotations to the bibliography.

Part one is simply two chapters of introduction to the book.  A somewhat
limited overview to security concepts is given in part two, concentrating on
the Internet.  Chapters look at the Internet, TCP/IP basics, hackers and
crackers, targets, possibilities of fights over the net, and very brief data
security primer.  Various types of security and attack software are outlined
in part three.  There is consideration of malicious software, security
weakness scanners, password crackers, trojans, network packet sniffers,
firewalls, and audit software.  Part four looks at specific operating
systems: Windows, UNIX, Novell, VMS, and Macintosh.  Two chapters look at
very basic security requirements in part five.  Network based attacks are
discussed in part six, reviewing levels of attack, spoofing, telnet,
scripting languages and extensions, and hiding of identity.  Different types
of resources and references are contained in appendices.  (I was
disappointed in the loss of a chapter on laws in various countries until I
found it had been moved back here.)

If you don't know security, this book is probably not going to teach it to
you.  On the other hand, if you work with security, you may find that some
of the resources listed here are things that you want to explore.  For the
novice it isn't altogether reliable, but for the professional it is at least
worth looking at.

copyright Robert M. Slade, 1998   BKMAXSEC.RVW   981025
rslade@vcn.bc.ca  rslade@sprint.ca  robertslade@usa.net  p1@canada.com
Robert Slade's Guide to Computer Viruses, 0-387-94663-2 (800-SPRINGER)


REVIEW: "Year 2000 in a Nutshell", Norman Shakespeare

"Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
Fri, 15 Jan 1999 08:18:30 -0800

BKY2KNSH.RVW   981030

"Year 2000 in a Nutshell", Norman Shakespeare, 1998, 1-56592-421-5,
U$19.95/C$29.95
%A   Norman Shakespeare
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   1998
%G   1-56592-421-5
%I   O'Reilly & Associates, Inc.
%O   U$19.95/C$29.95 800-998-9938 707-829-0515 nuts@ora.com
%P   336 p.
%T   "Year 2000 in a Nutshell: A Desktop Quick Reference"

*Can* the Year 2000 problem be put in a nutshell?  (Please?)

And isn't it just a tad late to be starting this?  (On the other hand,
Nutshell books *are* generally worth waiting for.)

Part one is a general overview of the situation.  Chapter one starts with a
rather exaggerated doomsday scenario, including concerns that have already
been seen, and thus have been addressed.  At the same time, it ignores the
"upstream" multiplier effect of supplier and infrastructure failures.
However, it does go on to note needs and concerns for management of the
potential failures.  Management and budgeting considerations are expanded in
chapter two.  Legal questions are addressed in chapter three, in a somewhat
generic fashion.  Some standard planning models and assumptions are given in
chapter four.  A little technical information in chapter five may help with
calculations for dates and windowing or packing solutions.  Chapter six
looks at the desktop PC; which is interesting in view of a very heavy COBOL
and IBM mainframe and mid-range emphasis elsewhere (as well as a few PC
related goofs in the doomsday scenario).  Unfortunately, some of the
information is missing and some is wrong in regard to the desktop.  There is
no mention of a "cold rollover" test for the CMOS/system date, and the
statement about Excel's date interpretation is incorrect.  (I have confirmed
this in my own testing.)  On the other hand, the warning about internally
developed applications is quite important.

Part two provides some forms and checklists to help organize a Year 2000
project, including triage, inventory, and a project template.  There are
about a hundred pages of COBOL references and tutorial in part three.  Date
functions get extensive listings in part four with attention to general
types, COBOL, PL/1, MVS LE, Visual Basic, and C.  There is a conceptual look
at code scanners in chapters eighteen and nineteen.  An appendix lists Web
sites for Y2K vendors, tools, and other resources.

Was it worth waiting for this?  I'm not sure.  There is little wrong with
the information, but neither is this a cut and dried quick fix that you
might expect from the Nutshell series.  An unrealistic expectation in the
case of the disaster of the century, admittedly, but there you are.  Still,
with the big iron emphasis, and the big project orientation, the material is
this work seems to be coming later than it would have been necessary to
start these kinds of projects.  There is relatively little in the volume for
small businesses depending upon desktop machines, and almost nothing on
fallback plans for non-compliance in the supply chain.  The material is fine
as far as it goes, but it doesn't go as far as it needs to at this late
date.

On the other hand, it's no worse than any of the others.

copyright Robert M. Slade, 1998   BKY2KNSH.RVW   981030
rslade@vcn.bc.ca  rslade@sprint.ca  robertslade@usa.net  p1@canada.com
Find virus, book info http://victoria.tc.ca/int-grps/techrev/rms.html

Please report problems with the web pages to the maintainer

Top