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 19

Monday 1 February 1999

Contents

o Complete ATC power failure in the U.S. Northwest
Paul Cox
o NYC 911 crash
David Lesher
o New attack on PGP keys with a Word Macro
Fred Cohen
o Intel's Pentium III Processor ID
Bruce Schneier
o Risks of successful security software
Nick Brown
o About the most bizarre Microsoft message yet
Fred Cohen
o Risks of using Windows95 as an embedded system
Steven J. Greenwald
o Government computer withholds benefit from British widows
Pete Mellor
o Re: not a Hotmail Web e-mail risk
John R Levine
o REVIEW: "The Transparent Society", David Brin
Rob Slade
o CFP: New Security Paradigms Workshop 1999
Mary Ellen Zurko
o SEPG '99: 11th Software Engineering Process Group Conference
Carol Biesecker
o Info on RISKS (comp.risks)

Complete ATC power failure in the U.S. Northwest

"Paul Cox" <pcox@eskimo.com>
Sun, 31 Jan 1999 22:36:22 -0800
Some time back, I wrote about some of the various risks involved with
air-traffic control computer-communication systems.  I mentioned how even
with backup systems controllers are still extremely vulnerable to the power
going out.

Well, it happened.  On 15 Jan 1999, at 2 pm, the power failed at Seattle
Center, an en-route ATC facility that covers nearly 300,000 square miles of
the NW United States.  I had the unusually good luck *not* to be at work at
the time.

The power failed during a normal, routine quarterly test procedure on the
power supply units.  To be honest, I don't understand the technical side of
how/why the power failed; I had it explained and I still didn't get it.  But
the gist of it was that during the test, a circuit board didn't do what it
was supposed to, and there was a very brief (less than a second)
interruption of the power to our systems.

Unfortunately, our systems cannot handle any interruption, and thus all the
computers had to be rebooted and recalibrated.  Our communication systems
failed completely, as they are totally computer-dependent, digitized,
touch-screen interface modules.  This system took over a half-hour to
reload.

Our main radar displays all went out as well, and the backup display system
failed too.  It took anywhere from 45 to 75 minutes for any radar displays
to come back at various sectors in the building.

Recall my description of how frantic controllers are when suddenly the
separation requirements for aircraft go from 5 miles to 20 miles (radar
environment to non-radar)?  That is exactly what happened.

The only system that DID work is a hard-wired, emergency radio backup system
that only needs power to be supplied to it, but which is old-fashioned
enough that it doesn't have computers running it.  Ironically, we had to
fight and fight and fight to have this system installed when our recent
upgrades took place.

Without it, we would have been completely helpless to communicate with any
aircraft in the area.  With it, we were able to restore limited ATC service
within a couple of minutes, falling back on the "good old days" method of
pilots staying on specific airways, reporting their progress over certain
points on the ground, and using paper strips, pencils, and our heads to
figure out whether anyone was in conflict with anyone else.

This failure simply drives home yet again that backup systems are only as
good as the main systems IF those backups are equally dependent upon a power
supply.  In fact, our backup communications system and backup radar display
systems were essentially worthless to us, because they failed at the same
instant as the main system did when the power died.

As long as you have a single point of failure in any system, it doesn't
matter how many backups you have downstream if they are dependent on that
point.

Fortunately, we still had the old-fashioned radios, not to mention the Mark
I Human Brain Wet Computers working for us.

Paul Cox  ZSE


NYC 911 crash

David Lesher <wb8foz@nrk.com>
Mon, 1 Feb 1999 11:33:58 -0500 (EST)
<http://www.newsday.com/ap/rnmpmt08.htm> and wire reports.

NYC 911 went down during a backup generator test. The backup system did not
function.

It took an hour to get the fallback running, and six hours to restart the
main system.  There were 4-per-year tests of the generators; but one wonders
how frequently the fallback system was deployed.

The RISK? Testing for failures often succeeds, but not where you thought.

In the "still works" department, a local reports NYC still has fireboxes,
and they were up. This is one of those "too simple to improve" technologies
-- a DC loop with clockwork-driven mechanical pulsers shorting to
ground. Break the loop and the boxes STILL work on the remaining leg.

voice (301) 56-LINUX

  [An AP item contributed by "corinsee" noted that a Vermont man died of
  an apparent heart attack during the outage while waiting for 911 to
  answer.  Many other RISKS readers commented on this case as well.  PGN]


New attack on PGP keys with a Word Macro

Fred Cohen <fc@all.net>
Fri, 29 Jan 1999 23:11:40 -0800 (PST)
I just got a look at a Word file (CALIG.DOC) that contains user IDs and
passwords to pornographic sites.  In addition to these pointers, it has a
Trojan Horse that finds the user's private PGP key ring and ftp's it to:

    209.201.88.110 (codebreakers.org)
    user anonymous
    password itsme@
    directory incoming
    binary mode
    stored name: NewSecRingFile[0-9][0-9][0-9][0-9]

This Trojan does its job in visual basic and - except for the initial notice
(if enabled) that macros are present - gives no indication of this function
that it performs. I figure the best defense against this is to:

1) Have thousands of users ftp phony files to that IP address
   and filename on a regular basis, thus making it impossible to
   get any real PGP keys - preferably send valid-looking PGP keys
   so they have to waste a lot of time cracking them.

2) Cut off all service for ftp with 209.201.88.110 (codebreakers.org)
   - either at the ISP, at your gateway, or at the borders to your country.

3) Prosecute for possession of access devices - with international
   cooperation between authorities.

4) Tell your people that this has been done so they will stop looking at
   pornography listing files fat chance this will work).

At any rate, I hope that you will take prudent precautions within your
organization against this potential attack on the security of your private
keys.

Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:925-454-0171
Fred Cohen at Sandia National Laboratories at tel:925-294-2087 fax:925-294-1225
  [Much-too-long disclaimer omitted, separating the two roles.  PGN]


Intel's Pentium III Processor ID

Bruce Schneier <schneier@counterpane.com>
Mon, 01 Feb 1999 17:05:03 -0600
Now is probably a good time to summarize the controversy regarding Intel's
Processor ID.

At the RSA Conference last month, Intel announced that it would be
embedding a unique ID number into every processor it sold:
http://www.redherring.com/insider/1999/0120/news-inteldongle.html
http://www.zdnet.com/zdnn/stories/news/0,4586,2190019,00.html

My initial comments, posted to ZDNet News, were as follows
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html>:

**********

Why Intel's ID tracker won't work
By Bruce Schneier, ZDNet News
January 26, 1999 4:45 PM PT

Last Thursday Intel Corp. announced that its new processor chips would come
equipped with ID numbers, a unique serial number burned into the chip
during manufacture. Intel said that this ID number will help facilitate
e-commerce, prevent fraud and promote digital content protection.

Unfortunately, it doesn't do any of these things.

 To see the problem, consider this analogy: Imagine that every person was
issued a unique identification number on a national ID card. A person would
have to show this card in order to engage in commerce, get medical care,
whatever. Such a system works, provided that the merchant, doctor, or
whoever can examine the card and verify that it hasn't been forged. Now
imagine that the merchants were not allowed to examine the card. They had
to ask the person for his ID number, and then accept whatever number the
person responded with. This system is only secure if you trust what the
person says.

The same problem exists with the Intel scheme.

Too easy to hack

Yes, the processor number is unique and cannot be changed, but the software
that queries the processor is not trusted. If a remote Web site queries a
processor ID, it has no way of knowing whether the number it gets back is a
real ID or a forged ID. Likewise, if a piece of software queries its
processor's ID, it has no way of knowing whether the number it gets back is
the real ID or whether a patch in the operating system trapped the call and
responded with a fake ID. Because Intel didn't bother creating a secure way
to query the ID, it will be easy to break the security.

As a cryptographer, I cannot design a secure system to validate
identification, enforce copy protection, or secure e-commerce using a
processor ID. It doesn't help. It's just too easy to hack.

This kind of system puts us in the same position we were in when the
government announced the Clipper chip: Those who are engaged in illicit
activities will subvert the system, while those who don't know any better
will find their privacy violated. I predict that patches that randomize the
ID number will be available on hacker Web sites within days of the new
chips hitting the streets.

The real question

The only positive usage for processor IDs is the one usage that Intel said
they would not do: Stolen processor tracking. Pentium II chips are so
valuable that trucks are hijacked on the highways, sometimes resulting in
drivers being killed. A database of stolen processor IDs would drop the
market for stolen CPUs to zero: Board manufacturers, computer companies,
resellers and customers could simply query the database to ensure that
their particular CPU wasn't stolen. (This is the primary usage for
automobile VINs.) This same system could be used to prevent manufacturers
from overclocking their CPUs -- running them faster than Intel rated them
for -- another thing that Intel would love to prevent.

The real question is whether computers are a dangerous technology, and need
to be individually tracked like handguns and automobiles. During the Cold
War many Eastern European countries required mimeograph machines to be
individually licensed; I have a hard time believing that computers need the
same sorts of controls.

**********

The controversy has been furious.  EPIC announced an Intel boycott (See
<http://www.bigbrotherinside.com/> for a good summary of the issues).

Intel backed off, saying that the feature would be initially turned off,
(see <http://www.zdnet.com/zdnn/stories/news/0,4586,2192717,00.html>), then
admitted that they had always intented to throw this bone to privacy groups.

More interesting were reports that there would be some kind of access
protocol designed to randomize the ID for different websites:
http://www.eet.com/story/OEG19990127S0011
http://www.eetimes.com/printableArticle?doc_id=OEG19990127S0033

And others have pointed out that dedicated hardware IDs have been around
for a while: Ethernet cards, hard drive IDS, etc.

So what's the difference, and what's the point?  Intel is pushing this
scheme as a way to prevent fraud.  I argued above, and I still maintain,
that it fails in that regard.  Even with the addition of a software
protocol, there is no way to prevent a program from intercepting the call
and replacing the ID number with a phony one.  I don't like this scheme not
because there's a unique ID, but because Intel is making impossible promises
about its utility.

             Free crypto newsletter.  See:  http://www.counterpane.com
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590


Risks of successful security software

BROWN Nick <Nick.BROWN@coe.fr>
Mon, 1 Feb 1999 09:24:57 +0100
The Daily Telegraph (London) reports that a hacker was so outraged when he
failed to beat the challenge laid down by Paul Smith, creator of network
security software called Access Denied, that he hacked into Mr. Smith's
credit records instead.  Mr. Smith is now trying to clear up a string of
false court judgements against him so that he can apply for a home loan.

Apparently the hacker was avenging his failure to break Access Denied,
having previously boasted to friends that he could do it in five minutes.

This would appear to indicate what might perhaps be considered an age-old
RISK: if you implement security measures professionally, make sure you can't
be identified personally by those potentially excluded by your measures.
Difficult to follow completely when your aim is to sell your software...

Nick Brown, Strasbourg, France


About the most bizarre Microsoft message yet

Fred Cohen <fc@all.net>
Sun, 31 Jan 1999 07:35:42 -0800 (PST)
I just got perhaps the most bizarre Microsoft error of all time.  I was
copying files from a network drive to a Jazz drive, and up pops an error box
with the message "Cannot copy sensitive countries" - at which point the copy
of all the files failed! It stopped on a filename corresponding to a country
whose name may well be on the sensitive countries list.

I guess Microsoft doesn't want us to use the names of certain countries in
our files!

Fred Cohen of
Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:925-454-0171


Risks of using Windows95 as an embedded system

"Steven J. Greenwald" <sjg6@gate.net>
Sat, 30 Jan 1999 21:07:38 -0500
This is really a case of a picture being worth ten thousand words, as
the Chinese old proverb says. I urge readers to take a look at
<http://home.studit.com/com00120/sparbanken1.jpg> and see what is
possibly the most foolish bank in the world.

If you can't view the picture, it shows a bank ATM, with the screen showing
a Windows95 error message. I can't tell what it says, as I am not fluent in
Swedish.

The risks here are so obvious it defies rationality as to why this bank
decided to do this.

Steven J. Greenwald  http://www.gate.net/~sjg6


Government computer withholds benefit from British widows

Pete Mellor <pm@csr.city.ac.uk>
Sat, 30 Jan 1999 17:30:28 GMT
From the "Moneybox" programme on BBC Radio 4 this morning:-

A computer system installed at a total cost of 140 million pounds sterling
(said to be the largest civilian system in Europe) is responsible for
underpayment of widows' benefits in the UK.

The system was originally scheduled for completion in February 1997. The
contractors now expect the remaining subsystems to be installed in March of
this year. Problems have apparently been caused by "software bugs", although
it was not clear from the programme to what extent software faults, as
opposed to late and incomplete delivery, are responsible for the trouble.
The basic problem appears to be that it has not been possible to input
complete and up-to-date records of all National Insurance contributions, on
which the widow's benefit is calculated.

The effect has been that women entitled to widow's benefit have been
underpaid for a period of up to two years by amounts ranging from one pound
to 100 pounds per week. The UK government in the meantime is sitting on one
billion pounds in unpaid benefits, and the interest that is accruing on
this.

There are a lot of angry widows beating on the doors of the Department of
Social Security. So far, they have not received an awful lot of help.  A
short time ago, the Liberal Democrat MP David Rendell drew attention to the
scandal by a question in Parliament. Steven Timms, Minister of State for
Social Security, said in interview on the programme that, from the 6th
January of this year, all *new* claimants would be paid correctly. He stated
that the NI contribution records would be up-to-date by the end of March,
and that existing beneficiaries whose total underpayment exceeded 100
pounds, and whose payment due for lost interest exceeded 10 pounds, would
automatically be reimbursed by lump sum payments for both underpaid benefits
and interest.

The government has set up a task force to deal with enquiries:-

  NI Benefit Task Force, Benefits Agency Department ST, Quarry House,
  Quarry Hill, Leeds LS2 7AU

I have quoted the above from memory, reinforced by a 'phone call to Radio 4
enquiries. Although I have tried to be as accurate as possible, anyone who
requires further details should send a SAE to:-

  Fact Sheet Week 5, Moneybox, Room 6239, BBC Television Centre,
  Wood Lane, Shepherds Bush, London W12 7RJ

Apparently, reports from current affairs programmes such as Moneybox are not
held on the BBC's website, due to lack of staff to input them.  However, a
detailed report also appeared in The Times on 26th January.

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


Re: not a Hotmail Web e-mail risk (Stasinksi*, RISKS-20.18)

John R Levine <johnl@iecc.com>
Sun, 31 Jan 1999 17:44:00 -0500 (EST)
This sounded pretty unlikely to me, so I asked the head of Hotmail's abuse
department about it.  He says that the drop box was cancelled promptly, and
they notified Mr. Stasinski.

John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner


REVIEW: "The Transparent Society", David Brin

"Rob Slade" <rslade@sprint.ca>
Fri, 6 Nov 1998 11:19:57 -0800
BKTRASOC.RVW   980919

"The Transparent Society", David Brin, 1998, 0-201-32802-X, U$25.00/C$34.95
%A   David Brin
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   1998
%G   0-201-32802-X
%I   Addison-Wesley Publishing Co.
%O   U$25.00/C$34.95 416-447-5101 fax: 416-443-0948 bkexpress@aw.com
%P   378 p.
%T   "The Transparent Society"

As the author points out, this book will probably be shelved alongside texts
on privacy.  It is, however, more properly about candour.  I find,
therefore, that I must make an admission of a rather important bias.
Despite being considered by some to be a security expert, I have never had
any particular interest in the practice of privacy and confidentiality.  I
am much more interested in openness.

Part one looks at the new transparent world as access to all kinds of
information increases.  Chapter one points out that the time to discuss
whether we want technology or privacy has passed: technology is here, and it
*will* provide access to information, and erode privacy, whether we like it
or not.  Brin does suggest that we still have a choice about the management
of that technology.  Do we want to have all data available only to a select
few (such as the government), or all data available to everyone?  The
"information age" is reviewed in chapter two, but there is also a very
interesting examination of the possibility of the resurgence of amateur
scholarship.  Various current invasions of, and attacks on, privacy are
discussed in chapter three.  In response to these, and in opposition to the
usual calls for more legislated protections on privacy, Brin proposes
reciprocal transparency: everyone who wants to collect information on the
public must make the same information about themselves publicly available.
Chapter four raises an extremely interesting point in relation to copyright,
patent, and other legal restrictions on intellectual property, and the fact
that the information age seems to have so much trouble with it.
Transparency initially seems to threaten to totally destroy the idea of
copyright, but ultimately may present a unique solution to maintaining its
proper function.

Part two looks at those problems involved in an open society.  Chapter five
presents some of the arguments that should be reviewed, from the toxicity of
ideas to the irony of western civilization's delight in individualism.  The
inherent benefits of accountability are reiterated in chapter six, although
with less eloquence and insight than earlier text displayed.  The encryption
debate is a convoluted one, and is fairly, but rather unclearly, portrayed
in chapter seven.  The general tone of most of the book is libertarian, so
the author does not seem to be completely comfortable with arguing against
the merits of confidentiality of communications.  It is, however, ironic
that Brin does not report the later research of Dorothy Denning that
indicates law enforcement agencies really do not need the ability to break
encryption, since in an odd way it strengthens his central thesis.

Part three proposes some means of achieving an open society.  Chapter eight
reviews a number of tools for transparency, but manages to look ragged and
disorganized.  Some future technological "tools races" are described with a
bit more coherence in chapter nine.  The various arguments in favour of
openness are extended, in chapter ten, to the international arena.  Chapter
eleven closes off with a summation of the rest of the book.

Since Brin is well known as a popularizer of science and as a science
fiction writer, and since his scientific training is not in the field of
information technology it would be easy to see this book as yet another
attempt by someone to trade on a reputation and a currently popular field in
order to make a few bucks with minimal effort and thought.  Although his
writing background has helped to produce a text that is easily readable, the
work is informed by a thorough understanding of the issues and technologies,
and also leavened with insight and wit.  Unfortunately, most of the really
good stuff comes in the first four chapters, leaving the rest of the volume
somewhat anticlimactic.

The book is both reasonable and provocative, and makes an interesting
counterpoint to much of the current discussion of privacy and technology.
Discussions of the important topics of privacy and encryption are both
balanced and quite complete, providing those near to the fields with a
useful primer.  In addition, Brin's more controversial points are well
taken, and deserve serious consideration.

copyright Robert M. Slade, 1998   BKTRASOC.RVW   980919


CFP: New Security Paradigms Workshop 1999

<Mary_Ellen_Zurko@iris.com>
Mon, 1 Feb 1999 09:17:57 -0500
                     Call For Papers
           New Security Paradigms Workshop 1999
              A workshop sponsored by ACM
                  22 - 24 September 1999
             Caledon Hills, Ontario, Canada
                  http://www.nspw.org
           [Starkly abridged for RISKS.  PGN]


The 1999 New Security Paradigms Workshop will take place from September 22 -
24, 1999 at The Millcroft Inn, an hour north of Toronto, Ontario, Canada.
In order to preserve the small, intimate nature of the workshop,
participation is limited to authors of accepted papers and conference
organizers.  Because these are new paradigms, we cannot predict what
subjects will be covered.  Any paper that presents a significant shift in
thinking about difficult security issues will be welcomed.

Program Co-Chairs:

Steven J. Greenwald                  Cristina Serban
2521 NE 135th Street                 AT&T Labs
North Miami, FL 33181 USA            307 Middletown-Lincroft Rd.
e-mail: sjg6@gate.net                Lincroft, NJ 07738 USA
voice: (305) 944-7842                e-mail:   cserban@att.com
fax: (305) 944-5746                  voice: (732) 576-3279
                                     fax: (732) 576-6406

  [See http://www.nspw.org for the full call for papers.
  The deadline for electronic submissions is 2 Apr 1999 --
  alternatively, 26 Mar 1999 for hardcopy.  PGN]


SEPG '99: 11th Software Engineering Process Group Conference

Carol Biesecker <cb@SEI.CMU.EDU>
31 Jan 1999 20:01:46 GMT
SEPG '99 - The 11th Software Engineering Process Group (SEPG) Conference
Software Process Improvement (SPI) Investments Today for a Changing Tomorrow
March 8-11, 1999, Hyatt Regency Atlanta, Atlanta, Georgia
FEB. 3, 1999 - Deadline for Early Bird Registration Discount
For complete details, including the preliminary program and information
visit the SEI Web site at
  http://www.sei.cmu.edu/products/events/sepg/

Download the registration form, available in portable document format
(PDF), then print, complete, and return this form to:
  Events, Software Engineering Institute
  Carnegie Mellon University
  Pittsburgh, PA 15213-3890
  FAX: 412 / 268-7401

The complete Preliminary Program is also available at the same Web site
in portable document format (PDF) for downloading or printing.  The

Please report problems with the web pages to the maintainer

Top