The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 18 Issue 90

Friday 14 March 1997

Contents

o Trojan-horsing around with video tapes
John Janieri via PGN
o Swedish Cracker Disrupts Florida 911 Systems
Edupage
o AOL Says It Got Incorrect Stock Info From S&P
Edupage
o News from the Land of Tamperproof Things
Peter Wayner
o NCAA Gives FBI Info on Web Site Vandalism
Edupage
o Dorothy Denning key-escrow/policy paper on-line
Mark Seecof
Dorothy Denning
o Hardening Your Computing Assets: Defending Against HERF and EMP
Carlo Kopp via Winn Schwartau
o Risks associated with upgrading to MS Office 97
Lloyd Wood
o Re: CaptiveX/Authenticode
Mark Bergman
o Risks of random-number server
Dan Drake
o Telephone Scam
Dewi Daniels
o Re: Not dead yet -- I'm still 3 degrees!
David Fetrow
o Re: The Ariane 5 explosion: software engineer's view
Kevin F. Quinn
o Keith Rhodes: Y2K duns contractor for 97-year delinquency
Robin Sheppard
o Y2K: the revenge of originality
Peter Vaneynde
o Y2K & UNIX & Netscape, the end is HERE
Geoffrey Cooper
o Y2K "problem" in virus?
Dean Matsen
o InfoWarCon 7: Call for Papers
Betty G. O'Hearn
o Info on RISKS (comp.risks)

Trojan-horsing around with video tapes

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Thu, 13 Mar 1997 11:21:45 PST
John V.A. Janieri in the Software Safety Research Group at Underwriters
Laboratories in Research Triangle Park NC sent me a copy of a letter
(undated, but received on 25 Jan 1997) that he received from Gateway 2000.
The RISKS-relevant excerpt is this:

  Dear Gateway Customer:  We are recalling our promotional video tapes
  made between December 20, 1996, and January 6, 1997.  It appears
  that an individual employed by an outside supplier to Gateway tampered
  with some of our video tapes and inserted offensive and objectionable
  material.  Enclosed is your new Gateway 2000 video tape.  The shrink
  wrapping on the new tape is your assurance that it is an official
  Gateway product.  It is also our guarantee that we have protected you
  and your family from the problem we've recently experienced.  [...]
  Dr. James Allen Taylor, Senior Vice President, Gateway 2000

I suppose John's association with UL is particularly appropriate in this
case, because the spoofed tapes in question had not only a writer, but an
under-writer ( la sous-chef).  On the other hand, I imagine that UL
would not underwrite the strength of the ``guarantees'' mentioned by
Dr. Taylor.


Swedish Cracker Disrupts Florida 911 Systems (Edupage)

Edupage Editors <educom@elanor.oit.unc.edu>
Sun, 9 Mar 1997 18:53:44 -0500
A Swedish computer cracker was able to dial into 11 north Florida 911
systems, tying up lines and harassing operators, the FBI reported Friday.
"In a few of them it was just a one-time incident where he would hook up a
911 operator with another 911 operator.  In other jurisdictions it was
multiple times," says an FBI agent.  The man has been arrested and convicted
of a misdemeanor in Sweden, because it has no laws that address electronic
intrusion.  (*Tampa Tribune*, 8 Mar 1997; Edupage, 9 March 1997)


AOL Says It Got Incorrect Stock Info From S&P (Edupage)

Edupage Editors <educom@elanor.oit.unc.edu>
Sun, 9 Mar 1997 18:53:44 -0500
While acknowledging that it posted some inaccurate information about Ben
Ezra Weinstein & Co., America Online blamed the problem on bad information
it had received from Standard & Poor, its stock information supplier.  An
AOL spokesperson says: "We don't make the stock prices.  All the information
is computer-translated, and occasionally the information we get is wrong."
But the chief operating officer for Ben Ezra Weinstein suggests otherwise:
"AOL just acknowledged that they've known about the problem for a few weeks
but couldn't correct it until they got a certain software.  When I asked AOL
to put that in writing, they wouldn't...  We believe the problem is with
AOL, and we have asked them to fix the problem and provide a screen saying
there been errors, and they haven't done either."  (*Atlanta
Journal-Constitution*, 7 Mar 1997; Edupage, 9 March 1997)


News from the Land of Tamperproof Things

Peter Wayner <pcw@access.digex.net>
Thu, 13 Mar 1997 16:12:57 -0500 (EST)
The *Wall Street Journal* (13 Mar 1997) reports that Roger Johnston, Los
Alamos employee, ``prides himself on being able to open anything-- and
without leaving a trace.'' The article continues to describe how he opens
sealed boxes, cargo bins, and shipping containers with ordinary dentist and
locksmith tools. He prides himself on not leaving any evidence of his
attack.  Although the article doesn't directly address tamperproof smart
cards popular in digital cash circles, it quotes Mr. Johnson as saying, ``We
haven't found anything that we can't defeat.''


NCAA Gives FBI Info on Web Site Vandalism (Edupage)

Edupage Editors <educom@elanor.oit.unc.edu>
Thu, 13 Mar 1997 14:03:55 -0500
The National Collegiate Athletic Association (NCAA), victimized by a vandal
who cracked into the NCAA's Web site to post racial slurs there, is turning
over to the FBI all details of the malicious entry.  The Kansas City Star
says it has identified the vandal as a 14-year-old high school freshman.
(AP, 12 Mar 1997; Edupage, 13 March 1997)


Dorothy Denning key-escrow/policy paper on-line

Mark Seecof <Mark.Seecof@latimes.com>
Thu, 13 Mar 1997 20:42:04 -0800
A recent paper presented by Dorothy Denning to the "Australian/OECD
Conference on Security, Privacy, etc. in the Global Information
Infrastructure" advocating key-escrow encryption and the criminalization of
secure cryptography is available at <http://www.nla.gov.au/gii/dd.html>.  I
recommend this paper to those interested in security policy issues.

The most important feature of the paper is Denning's refusal to recognize
the possibility of misconduct or incompetence by escrowed-key holders or the
governments to which they may be subject.  She does not even mention these
threats to dismiss them.

Dr. Denning expends a surprising number of words on the evils of
"crypto-anarchists," a group she defines (partly by omitting to mention any
middle-grounders) as all who disagree with her notions of proper
(in-)security methods.  She actually tars the IETF IP Security Working Group
with this brush.

Denning advocates restrictive licensing for the manufacture and use of
security software.  She does not mention any conflict between her proposals
and either the U.S.' 1st Amendment or various international human-rights
conventions.

While Denning cites and discusses remarks from a number of political
sources, and some technical ones with respect to key-escrow systems, she
does not cite any "uncongenial" technical sources (like, say, Matt Blaze)
nor discuss any work which might provoke anyone to question her conclusions.

Lastly, though she describes how info security may often be compromised
without breaking any ciphers (by, say, obtaining physical access to
computers) she also suggests that effective encryption would completely
stymie police agencies.  I beg to suggest that (a) effective encryption
would hardly leave police with fewer investigative means than they had
before people commonly had computers, and (b) police are much more able to
use non-cryptanalytic means to obtain information than, say, hackers.  For
example, encrypted digital telephones might baffle hackers and police alike,
but police could and would simply bug the rooms containing the 'phones to
obtain the conversations.  (Since Denning cites Russia for its
crytpo-licensing policy, I should cite it for the ultimate investigative
tool--questioning suspects under torture--which I was surprised to see
Denning did *not* count as a bad result of good encryption.  Maybe she will
next time, little as I care to assist her.)

Mark Seecof


Dorothy Denning key-escrow/policy paper on-line

Dorothy Denning <denning@cs.georgetown.edu>
Fri, 14 Mar 1997 16:28:52 -0500
The "recent" paper that Mark Seecof refers to is over a year old (even that
was a revision of a paper now 2 years old!).  It does not reflect my current
thinking, and I too find much to criticize in it.  Readers interested in my
recent thinking (which is constantly undergoing revision!)  should read my
latest paper "Encryption Policy and Market Trends".  All of the papers
mentioned here are available at http://www.cs.georgetown.edu/~denning/crypto/ .

Mr. Seecof has read much between the lines of my paper that are not
supported by facts.  Even though I did not write about it in the paper, I do
recognize the potential for misconduct or incompetence on the part of key
escrow agents or governments.  It was one reason why I signed up to review
the government's Clipper system in 1993.  I wanted to help make sure that
that system had extremely good safeguards.  Some of my other papers say more
on this topic.  For example, the following is from "Encrypting the Global
Information Infrastructure," Aug.  19, 1996:

     "Large-scale deployment of key escrow introduces some risk into the
     infrastructure.  Key escrow is not likely to be accepted unless
     users are convinced that these risks have been made negligible
     through technical, legal, and procedural safeguards, and that they
     will be able to recover losses in case of abuse.  Users will want
     to be able to pick key holders they trust.  They will want
     assurances that key escrow will not be exploited by corrupt
     governments to violate human rights and that
     government-to-government agreements will not make them vulnerable
     to foreign espionage."

In that paper I was not advocating mandatory key escrow.  In the paper
Seecof refers to, I did discuss the possibility of such controls on the
manufacture and distribution (but not use) of encryption products.  I
believe it is important that we openly discuss a variety of options.
However, I have not advocated mandatory key escrow.  I do advocate the
use of strong cryptography, and I advocate key recovery systems as good
business policy.

I did not mean to suggest that people who disagree with me are evil or that
cryptoanarchists are evil.  It was particularly unfortunate that my mention
of the IETF was interpreted to mean that I viewed them as either
cryptoanarchists or evil.  I have considerable respect for many of the
people who work on the standards, and I support the standards they have
developed.  The crypto in IPv6 is a good thing!

I have written about export controls on encryption software and 1st
Amendment issues.  See "Export Controls, Encryption Software, and Speech."
See also "Is Encryption Speech?"

Yes, I could have cited more sources than I did and said more than I said.
By all means, read the works by Matt Blaze and others.

I am currently in the middle of a more comprehensive study of the impact of
crypto on crime and terrorism.  Input welcome, especially from people with
actual case experience.  Stay tuned.

Dorothy Denning


Hardening Your Computing Assets: Defending Against HERF and EMP

by way of "Betty G. O'Hearn" <betty@infowar.com> <winn@infowar.com>
Wed, 12 Mar 1997 13:59:31 -0500
The Subject: line is the title of another excellent paper by Mr. Carlo Kopp,
a noted defence analyst and aviation writer from Australia.  This is a HERF
Guns and Magnetic Weapons update.  The paper is very understandable with
methods for protecting computer systems and networks from externally induced
power events that can cause havoc with electronic systems and controls.

Mr. Kopp provides excellent graphics to further illustrate his
recommendations on Defending IW, Site Hardening, and Hardening Computer
Equipment.  For extreme denial of service attacks and terrorist worries,
this is a fine example of creative thinking and defensive posture.

Kopp states, "Indeed, the commercial opportunities for smaller manufacturers
in the production of hardened equipment chassis and interfaces, using
standard commercial internals, are considerable in the medium term.  We can
hope that our industry will rise to this challenge."

I highly recommend this well written and informative piece. It is available at no charge on www.infowar.com, at URL:
  http://www.infowar.com/class_3/harden.html-ssi

Winn Schwartau  www.infowar.com  www.info-sec.com


Risks associated with upgrading to MS Office 97

Lloyd Wood <L.Wood@surrey.ac.uk>
Thu, 13 Mar 1997 16:29:30 +0000 (GMT)
This was a university-wide advice memo received today.

It illustrates some of the risks of relying on a product with a publically
undocumented proprietary data format with an all-new internal format; you
have to wait for third-parties to get the information they need, and provide
essential support for problems that shouldn't exist in the first place --
like recovery of files damaged, perhaps by Office macro viruses.

<URL:http://www.sat-net.com/L.Wood/><L.Wood@ieee.org>+44-1483-300800x3435
[and I want 'open standards' tattooed on my forehead.]

 - - - - - Forwarded message - - - - -
Date: Thu, 13 Mar 1997 12:43:23 +0000
>From: XXX
To: XXX
Subject: Risks associated with upgrading to MS Office 97

***Use caution when upgrading to Microsoft Office 97***

The Microsoft Office 97 suite uses different file formats to that used in
the earlier version. This means that earlier virus protection products will
not afford the level of protection all user require and expect from their
previously installed anti-virus software.

Microsoft have acknowledged the fact that in the rush to market the product,
they did not release the information regarding this change of file format to
anti-virus vendors in time for them to prepare their products.

In any event, the University's site licensed anti-virus product, McAfee
VirusScan 2.5.x DOES NOT afford Office 97 users an adequate level of
protection. This version, and earlier versions of McAfee have been available
from the UCS Service Desk for some time.

McAfee recently launched (March 3, 1997) VirusScan 3.0 with the Hunter(tm)
Virus Detection Engine that includes Office 97 Macro virus protection and it
successfully detected 100% of viruses in the latest Secure Computing
Magazine review (McAfee's statement-for details of the tests please consult
the magazine as this reported success rate does depend on the test
conditions).  UCS are awaiting the arrival of this latest version.

Whilst this article refers to McAfee anti-virus products, you must check
with other vendors such as Symantec and Dr Solomon for up to date news if
you use their products.

[sig snipped. UCS = University Computing Services]


Re: CaptiveX/Authenticode (Baker RISKS-18.89)

Mark Bergman <bergman@panix.com>
14 Mar 1997 15:20:27 -0500
I think the perception issues are more serious than [Henry Baker states].  I
was recently part of a planning meeting where a strategic shift from Apple
to Wintel platforms was discussed.  One of the arguments in favor of Windows
95 (from a senior molecular-biochemist) was that "Apple keeps releasing all
these patches and bug fixes and upgrades to their operating system, while
Microsoft hasn't released anything for Windows95" as evidence that Win95 is
therefore bug-free.

The RISK?  Things are worst when they appear best.  Even smart people don't
always get it.

Mark Bergman    Biker, IATSE #1 Stagehand, Unix mechanic
718-855-9148    bergman@panix.com   {cmcl2,uunet}!panix!bergman


Risks of random-number server (Re: Wing, RISKS-18.89)

Dan Drake <drake@A.crl.com>
Thu, 13 Mar 97 09:42:55 -0800
First, a bias disclosure: as a friend of the provider of the service
described here, I'm more annoyed by this carping than other people might
be. Now then,

[Description of quantum-based random-number server at
http://www.fourmilab.ch/hotbits/, followed by] >

 > An interesting idea, but hopefully nobody will use it -- it is too easily
 > spoofed via DNS, and the host itself could be hacked to return the same
 > 'random' number all the time.  ...

What, nobody? How about people who know who's providing the service, and
can make a reasonable comparison between the hacking probability at his
site versus that at other sites, like the Department of Defense?

How about people with the sense to run occasional spot checks on the
output to see if it looks reasonably random?

Of course, the guys in the black helicopters could pollute the data, via DNS
spoofing or whatever, only occasionally, and instead of returning the same
number all the time, they could replace these quantum random numbers with
output from some Microsoft random() function to circumvent the spot checks.

The Risks question here is, just what level of paranoia is suitable here?

The real risk here is that this may annoy John enough that he'll waste his
valuable time adding a PGP signature capability to the random-number output.

Spoof that.

Dan Drake  dandrake@netcom.com  http://www.nbn.com/people/dandrake/index.html


Telephone Scam

Dewi Daniels <dewi@cableol.co.uk>
Fri, 14 Mar 1997 12:07:26 GMT
We had a nasty shock a couple of days ago, when we received our monthly
phone bill from our cable telephone operator, CableTel. The last two days of
the billing period, there had been a number of calls to the same number in
Guyana, totalling UKP 75, more than doubling our phone bill. On each day,
there had been three calls in succession, making a total of six calls.

We placed a bar on premium rate and international calls as soon as we
received the bill. I'm concerned these calls may have continued to be made
during the week that elapsed before we received the bill, so we could be
liable for another UKP 250 or more.

We got in touch with CableTel, who claim that these calls had originated as
premium rate calls to an 'entertainment' line, and that their records showed
these calls must have been made from our house.

Now, we're sure that nobody made these calls from our house. I was in the
USA at the time, and my wife was at work. A married couple, old friends of
ours, were staying with us. At the time of the calls, the husband was at
home, studying for his Open University degree, and the wife was at work. We
had no workmen or other visitors in the house those days.

It's not clear yet whether CableTel are going to hold us liable for these
charges. It is clear that they suspect our friends. I can't say I blame them
for coming to that conclusion, but we have every reason to believe that our
friends are perfectly trustworthy, and are sure that the explanation must
lie elsewhere.

As a software safety engineer, and a regular reader of the RISKS Digest, I'm
well aware there may be any number of ways in which these calls could have
been charged to our account. I find CableTel's claims that their computer
records 'prove' the calls were made from our house to be rather less than
satisfying.

I don't have any detailed knowledge of telephony or telephone billing
systems. I do, however, respect the technical knowledge of my fellow
subscribers to this list. Does anyone have any theories as to how these
calls could have been charged to our account, or has anyone heard of any
similar cases?

I'd be very grateful indeed for any suggestions as to how we should
proceed in presenting our case to CableTel.

Dewi Daniels  Guildford, England

  [Please reply to Dewi, cc:ing RISKS.  Dewi, please
  summarize your answers for RISKS.  TNX.  PGN]


Re: Not dead yet -- I'm still 3 degrees! (Seurer, RISKS-18.87)

David Fetrow <fetrow@biostat.washington.edu>
Fri, 14 Mar 1997 10:44:47 -0800 (PST)
> On a medical device with 4 digits output what sort of meaningful error code
> would you expect?  [...]

Although these are valid points and it's just a thermometer:

Hospital medical equipment must be utterly clear about what the problem is
without consulting a manual (or even the bottom of the unit). If that means
spending an extra $2 for an alphanumeric display so be it.

Error codes such as a "3" are NOT OK.  Even if it's "obvious when you think
about it" this kind of error code means the caregiver is spending time
diagnosing a box of electronics and not the patient.

Throw in a lack of standardization of what the codes mean, a need not to
pick up random stuff with gloved hands, time constraints, temporary help,
hooking people up to a dozen devices.... There hardly seems enough attention
left to deal with a patient.


Re: The Ariane 5 explosion: software engineer's view (Baber, R-18.89)

"Kevin F. Quinn" <kfq@wormhole.compd.com>
Fri, 14 Mar 1997 12:22:24 +0000
I think it is worth noting that there are many commonly-used engineering
techniques that would have detected the fault during development, some of
which are mentioned in the inquiry board's report as having been
compromised.

Application of correctness-proof techniques as described by Professor Baker
could no doubt have detected the failure, unfortunately such techniques
require a facility in mathematics that is rare in software engineers (and in
almost all other groups, for that matter).  The potential for error in
application of such techniques surely has to be considered.  Unquestionably
when accurately applied the techniques could have avoided the problem, but
how accurately would they be deployed in practice?  The same is true of
other engineering practices designed to avoid such failures; those in use on
the Ariane 5 programme if rigorously applied would have detected the fault.

(The report mentions several cases where practices were deliberately
compromised in this case; continued operation of the alignment function
after lift-off - that function being meaningless after lift off on Ariane
5, lack of redundant software in the two SRIs, lack of closed-loop system
testing including the SRIs, not designing flight-critical equipment as
fail-operate where possible, and so on.)

The risk is to trust any particular engineering technique when so much else
can compromise the system without compromising the technique as such itself
(i.e. assuming that the technique is accurately applied).  In this case, my
understanding is that an assumption was made that the BH (horizontal bias)
value would not exceed the expected range for the alignment function.  The
assumption possibly arising from only considering the alignment function in
a pre-lift off situation, which given that the function is meaningless after
lift-off would not be unreasonable.  It is easy to conceive that in the same
environment, formal methods of proof would be applied under the same
assumptions, and hence could be compromised in the same fashion.

Kevin F. Quinn - Software Engineer  kfq@wormhole.compd.com (work)
kevq@banana.demon.co.uk (home)  http://www.banana.demon.co.uk/


Keith Rhodes: Y2K duns contractor for 97-year delinquency

Robin Sheppard <robinsheppard@technologist.com>
Thu, 13 Mar 1997 07:43:24 -0800 (PST)
RISKs of things to come:

>From *The Napa Sentinel* (Napa, CA), March 7, 1997:

"In testimony last week before the House Government Reform Committee, Keith
Rhodes of the Government Accounting Office described what happened when a
three-year defense contract was awarded last month, for completion in
January 2000.  A computer read the date as 1900 (the last 2 digits), and
sent the contractor a 97-year delinquency notice."

The writer opined that "It stands to reason.  Before they could invent
artificial intelligence, they had to come up with artificial dumbness."

Robin Sheppard  robinsheppard@technologist.com


Y2K: the revenge of originality

"Peter.Vaneynde" <s950045@uia.ua.ac.be>
Mon, 24 Feb 1997 09:44:10 +0100 (MET)
A few days ago I had a conversation with an old friend who now works with a
subcontractor at one of the largest insurers in this country.  He told me
that he was working on the Y2K problem (in COBOL; I offered my condolances).
I asked how many lines of code he could check in a day.  I was quite
surprised to learn that they only did a search for names that alluded to the
involvement of dates (date|time|datum|tijd etc).  Later I remembered an
other conversation with a neighbor who works at an other insurer: he told me
of a colleague who used nonsense words as identifiers (dada, pipi, woef,
miauw, etc).

Exercise for the reader: what is the chance that similar "problem-solving"
techniques touch code generated by "original" programmers?
Man, _now_  I'm scared about 2000.


Y2K & UNIX & Netscape, the end is HERE

Geoffrey Cooper <geof@devices.com>
Tue, 11 Mar 1997 14:30:02 -0800
Well, we added Y2K support for our new little Twister web server box, which
has a PC-compatible time chip in it (yes, I know, but it was cheap).  Then
we found that Netscape 3.0 was crashing on certain files.  One machine was
initialized incorrectly, and was serving up file-modification times as the
year 2050.  Netscape appears to cache the file with a UNIX-compatible time
stamp, and 2050 is a negative date.

We decided to retire the product in (or at least upgrade the flash ROM
by) the year 2037.

Geoffrey Cooper, Compact Devices, Inc., Campbell, CA  408 255 4200
geof@devices.com


Y2K "problem" in virus?

Dean Matsen <dmatsen@halcyon.com>
Sun, 23 Feb 1997 00:45:16 GMT
> Has anyone bothered to look and see if the Michaelangelo virus will be
> bitten by the Y2K problem?  One can only hope...

I have actually seen and disassembled the Michaelangelo virus code.  It
doesn't care what year it is, only that it's March 6th -- This virus will be
a risk as long as it lives.  Bummer.


InfoWarCon 7: Call for Papers

"Betty G. O'Hearn" <betty@infowar.com>
Fri, 14 Mar 1997 14:58:44 -0500
   Defensive Information Warfare and Systems Assurance
        For Community, Company and Country
Sheraton Premier, Tysons Corner, VA, September 11-12, 1997
                   Call for Papers

Sponsors: National Computer Security Association <http://www.ncsa.com>
  and Winn Schwartau, Interpact, Inc. <http://www.infowar.com>
  and <http://www.info-sec.com>
Submission Deadline: May 16, 1997
For complete information on attendance:
  Registration: Conferences@ncsa.com
  Sponsorships: Sponsors@ncsa.com
Questions/Help: betty@infowar.com

Please report problems with the web pages to the maintainer

Top