Text File

precedence: bulk Subject: Risks Digest 20.19

RISKS-LIST: Risks-Forum Digest Monday 1 February 1999 Volume 20 : Issue 19

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.19.html> and at ftp.sri.com/risks/ .

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

----------------------------------------------------------------------

Date: Sun, 31 Jan 1999 22:36:22 -0800 From: "Paul Cox" <pcox@eskimo.com> Subject: Complete ATC power failure in the U.S. Northwest

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

------------------------------

Date: Mon, 1 Feb 1999 11:33:58 -0500 (EST) From: David Lesher <wb8foz@nrk.com> Subject: NYC 911 crash

<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]

------------------------------

Date: Fri, 29 Jan 1999 23:11:40 -0800 (PST) From: Fred Cohen <fc@all.net> Subject: New attack on PGP keys with a Word Macro

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]

------------------------------

Date: Mon, 01 Feb 1999 17:05:03 -0600 From: Bruce Schneier <schneier@counterpane.com> Subject: Intel's Pentium III Processor ID

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

------------------------------

Date: Mon, 1 Feb 1999 09:24:57 +0100 From: BROWN Nick <Nick.BROWN@coe.fr> Subject: Risks of successful security software

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

------------------------------

Date: Sun, 31 Jan 1999 07:35:42 -0800 (PST) From: Fred Cohen <fc@all.net> Subject: About the most bizarre Microsoft message yet

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

------------------------------

Date: Sat, 30 Jan 1999 21:07:38 -0500 From: "Steven J. Greenwald" <sjg6@gate.net> Subject: Risks of using Windows95 as an embedded system

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

------------------------------

Date: Sat, 30 Jan 1999 17:30:28 GMT From: Pete Mellor <pm@csr.city.ac.uk> Subject: Government computer withholds benefit from British widows

>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

------------------------------

Date: Sun, 31 Jan 1999 17:44:00 -0500 (EST) From: John R Levine <johnl@iecc.com> Subject: Re: not a Hotmail Web e-mail risk (Stasinksi*, RISKS-20.18)

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

------------------------------

Date: Fri, 6 Nov 1998 11:19:57 -0800 From: "Rob Slade" <rslade@sprint.ca> Subject: REVIEW: "The Transparent Society", David Brin

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

------------------------------

Date: Mon, 1 Feb 1999 09:17:57 -0500 From: Mary_Ellen_Zurko@iris.com Subject: CFP: New Security Paradigms Workshop 1999

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]

------------------------------

Date: 31 Jan 1999 20:01:46 GMT From: cb@SEI.CMU.EDU (Carol Biesecker) Subject: SEPG '99: 11th Software Engineering Process Group Conference

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

------------------------------

Date: 23 Sep 1998 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

------------------------------

End of RISKS-FORUM Digest 20.19 ************************