Text File

precedence: bulk Subject: Risks Digest 20.47

RISKS-LIST: Risks-Forum Digest Saturday 10 July 1999 Volume 20 : Issue 47

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.47.html> and at ftp.sri.com/risks/ .

Contents: Electronics startup transient kills spacecraft (Craig DeForest) NASA discloses space station blunder (Wayne Mesard) Space Station AOL hack (Marc Passy) Busy phone lines block stay of execution (Joe Thompson) E-mail writer arrested for starting panic (Matthew Todd) Garciaparricide in All-Star balloting? (PGN) Custodiet ipsos custodes? Not without permission! (Adam Shostack) Singapore exchange blames outage on network failure (Paul Walker) eBay outage traced to failure to upgrade (Steve Klein) Australian virtual reality kanga-rues the day (Lindsay Marshall) Faulty vending machines block emergency calls in Australia (Mark Nottingham) Brazilian telephone network chaos (Matthew Todd) Spell-checker run amok? Shandling-->Changeling (Jim Griffith) REVIEW: "Computer Security", Dieter Gollmann (Rob Slade) REVIEW: "Securing Java", Gary McGraw/Edward W. Felten (Rob Slade) Abridged info on RISKS (comp.risks)

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

Date: Tue, 29 Jun 1999 10:27:17 -0700 From: craig@deforest.org Subject: Electronics startup transient kills spacecraft

A recent (25 Jun 1999) press release from NASA HQ identifies the untimely demise of the Wide Field Infrared Explorer (WIRE) spacecraft as due to a design flaw in the pyro control logic board. WIRE's detector was to be cooled with a block of solid hydrogen. The telescope cover's explosive release mechanism fired immediately when the instrument was powered up, exposing the detector to direct sunlight and sublimating all of the solid hydrogen on board within 48 hours of its 5-Mar-99 launch. Unbalanced thrust from the hydrogen venting gave the spacecraft an uncontrolled 60 RPM spin.

The telescope cover was ejected prematurely because "the transient performance of components was not adequately considered in the [electronics] design. ... The start-up time of the ... clock oscillator was not taken into consideration, leaving the circuit in a non-deterministic state for a time sufficient for pyrotechnic actuation", according to the executive summary of the failure investigation report.

Contributing factors in the program included the lack of any peer review for the pyro box design (due to it not being completed at the time of the spacecraft SDR), insufficient interlocks in the pyro control circuits, and low fidelity of the ground support equipment used for preflight testing.

The executive summary of the report is available on the World Wide Web at "ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/wire_summary.pdf".

Better, faster, cheaper: choose any two.

Craig DeForest

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

Date: Tue, 22 Jun 1999 17:22:01 -0400 From: Wayne.Mesard@East.Sun.COM Subject: NASA discloses space station blunder (RISKS-20.46)

> NASA said [the station's engines failed to fire] > because of human error.

> Initially the rocket chunk [was predicted to] pass within two-thirds > of a mile of the space station on Sunday. It ended up coming no closer > than 4 1/2 miles.

Isn't this latter fact the real risk here? What is the average predictive error for space debris near-misses? Since we are counting on the accuracy of these predictions to protect people and expensive equipment, I would hope it is less than 575%.

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

Date: Tue, 29 Jun 1999 22:58:55 -0500 From: Marc P <passy#no_spam#@flex.net> Subject: Space Station AOL hack

The server on which the International Space Station Problem Reporting database resides was recently "hacked," prompting its disconnection from *all* networks, including the local LAN, for security upgrades. This database is used by the hundreds of users here at Johnson Space Center and at the various development sites around the country to document problems and direct fix work with hardware, software, and documentation for all parts of the ISS

Similar to problems AOL has had, it seems that someone, most likely someone involved with the ISS program, obtained the name of a user with administrator access, then called the help desk and asked for a password reset. They were promptly given that new password, after which they proceeded to do something objectionable with the password file. (That part's still not quite been released.)

It doesn't appear that the database was damaged, but the access removal brought productive work reviewing problems and working fixes almost to a standstill.

Aside from other measures, and to add insult to injury, they are asking for a "PIN" to use to help identify the user if they call for resets. They asked that these "PINs" be chosen by the user and sent via CLEAR TEXT E-MAIL!!!!!!!

Besides which, if I forget a password that I use every couple of days, and I call for a reset, how am I going to remember a "PIN" that I specified six months before???

To reach me, you might try passy (at) flex (dot) Net.

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

Date: Fri, 25 Jun 1999 11:18:52 -0700 (PDT) From: Joe Thompson <joe@orion-com.com> Subject: Busy phone lines block stay of execution

http://www.cnn.com/WORLD/asiapcf/9906/25/philippine.execution.02/

Summary: Due to phone problems, a stay of execution by the Philippine president could not be delivered in time to save the condemned prisoner. By the time the president's office got through to the prison, the lethal injection had already been administered. From the published details it's unclear whether the phone lines were misdirected in the system, or the president's office was calling the wrong number. -- Joe

Joe Thompson, Charlottesville, VA joe@orion-com.com http://kensey.home.mindspring.com/

[Also noted by Robert Franchi in *The Boston Globe*, 18 Jun 1999: He was scheduled to be executed for raping his own daughter. The governor of the Philippines finally relented to grant a stay of execution 5 minutes before the scheduled time. He could not get through on the phone or fax, and when he finally did get through, the man had been dead of lethal injection for 1 minute. PGN]

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

Date: Thu, 8 Jul 1999 13:25:40 +0600 From: "Matthew Todd" <matthew@mail.cmb.ac.lk> Subject: E-mail writer arrested for starting panic

Jose Omar Olaya, 24, was arrested for sending false e-mail messages from Hotmail urging everyone to take their money out of Davivienda Bank because of a pending government intervention. In the resulting panic, $11.4M was withdrawn in one day, and the Columbian government had to cover the outflux. [Source: AP item in *The Island*, 6 Jul 1999, from Bogota; PGN-ed]

RISKS and QUESTIONS:

1. The obvious one of spreading unsubstantiated rumours by email, which applies equally to financial information or computer viruses, or anything else.

2. Since Hotmail accounts are notoriously anonymous, how was this tracked back to him so that he could be arrested?

[Anonymity is generally only a relative concept. Who pays the bills? PGN]

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

Date: Fri, 9 Jul 1999 11:22:48 -040 From: "Peter G. Neumann" <Neumann@csl.sri.com> Subject: Garciaparricide in All-Star balloting?

Boston Red Sox shortstop Nomar Garciaparra was running behind in the open balloting. As part of a huge last-day Internet deluge, Sox fan Chris Nandor cast 25,259 votes for him and other Red Sox players via the Internet. (Just a little Perl script.) However, the administrators of the balloting were able to detect the violation of the 22-vote maximum, because he used the same e-mail address each time, the same bogus phone number and zip code. (that's NAND-OR logic?) However, Garciaparra managed to pull from behind in other late votes that were apparently legitimate. [Source: PGN-ed from numerous media reports on 7 Jul 1999 from several contributors, including PGN who saw it in *The Boston Globe* and *The New York Times*.] One might wonder how many multiple votes were NOT caught.

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

Date: Sun, 4 Jul 1999 06:35:20 -0400 From: Adam Shostack <adam@bindview.com> Subject: Custodiet ipsos custodes? Not without permission!

In the case of Michael Hyde vs Abington (Massachusetts), Mr. Hyde was found guilty of violating state wiretap laws, which forbid recording the voice of a person without their knowledge. Mr Hyde recorded the police being abusive towards him, using profanity threatening him with jail. When he brought the tape to the Abington police, they charged him with violations of the wiretap statue. He has been sentenced to six months probation and a $500 fine.

It seems clear that if it is not possibly to surreptitiously monitor the police for abuse of their powers, such abuses are less likely to be caught and corrected.

*The Boston Globe* is very bad about maintaining URLs, but try http://www.boston.com/dailyglobe2/184/metro/Driver_guilty_in_taping_of_police%2b.shtml

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

Date: Mon, 21 Jun 1999 12:32:23 +0530 From: "Walker, Paul (India)" <paul_walker@in.ml.com> Subject: Singapore exchange blames outage on network failure

Well, I am glad to see that the powers-that-be had: - a contingency plan in place - someone to oversee the Friday evening test has complete successfully - excellent error messages to allow the operators to quickly identify the cause of the problem - someone involved with the process with an overall understanding on what is being done with the system

- Paul <paul.walker@jamesmartin.com>

Singapore exchange blames outage on network failure

The Stock Exchange of Singapore [http://www.ses.com.sg] announced late Tuesday that the systems outage that left traders unable to complete any orders on Monday morning was caused by the failure of a communications link. The exchange said they became aware of the trading system failure at 8:10am on Monday and discovered the system was quickly shutting down every time it was restarted. After system checks revealed no problems, the exchange decided to switch to back up data from late Friday and then discovered a back up process at the Business Recovery Centre was still running. A Friday evening test on a communications link between the exchange and center had left the link down and this had kept the back up process running, explained the exchange in a statement. In an attempt to reassure investors, the exchange said "the trading system is sound," and announced "stringent procedures are being implemented to detect any failure to shutdown the systems properly. Checks are being put in place to ensure complete deactivation of systems before the commencement of any test." "With these measures, the problem should not recur," said the exchange.

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

Date: Mon, 21 Jun 1999 16:30:13 -0400 From: "Steve Klein" <klein@dcds.edu> Subject: eBay outage traced to failure to upgrade

The outage at eBay was traced to a problem with the Solaris operating system, which overwrote files and corrupted their database.

According to PC Week Online:

"eBay had not upgraded the system with an available Solaris patch to fix the overwriting error...

The patch was available for several months for downloading from Sun's Web site, although Sun officials acknowledged they should have been more proactive in implementing it for eBay."

http://www.zdnet.com/pcweek/stories/jumps/0,4270,407390,00.html

Ironically, eBay was just 3 or 4 days away from deploying a "warm standby" backup system they had been installing for five months.

System administrators typically view patches and updates with some trepidation. We've postponed upgrades because experience has shown that upgrades often carry their own RISKS.

We shouldn't ignore the fact that NOT upgrading can also be RISKy.

Steve Klein phone (248) 646-7717 x 1119 Technology Specialist, Detroit Country Day School

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

Date: Wed, 23 Jun 1999 13:22:23 +0100 (GMT) From: Lindsay.Marshall@newcastle.ac.uk Subject: Australian virtual reality kanga-rues the day

>From rec.humor.funny....

This is supposedly a true story from a recent Defence Science Lectures Series, as related by the head of the Australian DSTO's Land Operations/Simulation division.

They've been working on some really nifty virtual reality simulators, the case in point being to incorporate Armed Reconnaissance Helicopters into exercises (from the data fusion point of view). Most of the people they employ on this sort of thing are ex- (or future) computer game programmers. Anyway, as part of the reality parameters, they include things like trees and animals. For the Australian simulation they included kangaroos. In particular, they had to model kangaroo movements and reactions to helicopters (since hordes of disturbed kangaroos might well give away a helicopter's position).

Being good programmers, they just stole some code (which was originally used to model infantry detachments reactions under the same stimuli), and changed the mapped icon, the speed parameters, etc. The first time they've gone to demonstrate this to some visiting Americans, the hotshot pilots have decided to get "down and dirty" with the virtual kangaroos. So, they buzz them, and watch them scatter. The visiting Americans nod appreciatively... then gape as the kangaroos duck around a hill, and launch about two dozen Stinger missiles at the hapless helicopter. Programmers look rather embarrassed at forgetting to remove *that* part of the infantry coding... and Americans leave muttering comments about not wanting to mess with the Aussie wildlife...

As an addendum, simulator pilots from that point onwards avoided kangaroos like the plague, just like they were meant to do in the first place...

[Also noted by Scott Rainey. PGN]

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

Date: Mon, 5 Jul 1999 10:09:42 +1000 From: "Nottingham, Mark (Australia)" <mark_nottingham@exchange.au.ml.com> Subject: Faulty vending machines block emergency calls in Australia

<http://www.techserver.com/noframes/story/0,2294,66895-105845-751208-0,00.html>

The default phone number in vending machines in Sydney is 000, which just happens to be the emergency phone number (a la 911 in the U.S.). As a result, hundreds of calls were made to emergency phone lines, blocking genuine calls. Authorities were trying to figure out how many of the million bogus calls a year are related to this source. [Source: AP item, 3 July; PGN-ed; also noted my others.]

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

Date: Tue, 6 Jul 1999 10:08:26 +0600 From: "Matthew Todd" <matthew@mail.cmb.ac.lk> Subject: Brazilian telephone network chaos

I heard a report on the BBC World Service news this morning, 6 July, that only 15% of long distance telephone calls made in Brazil yesterday were connected correctly. Apparently, a new dialing system was introduced over the weekend, which means people must now dial two extra digits. Residential customers have been asked not to make long distance calls during working hours for the next few days.

Matthew Todd, Lecturer in Computer Science, University of Colombo

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

Date: Fri, 2 Jul 1999 14:57:06 -0700 (PDT) From: Jim Griffith <griffith@netcom.com> Subject: Spell-checker run amok? Shandling-->Changeling

CNN recently put a story on their entertainment page about a lawsuit which Garry Shandling filed against his former manager. However, other than the title, Shandling's name was changed throughout the article to "Changeling". Can you say "spell-checker"?

http://www.cnn.com/SHOWBIZ/News/9907/02/showbuzz/index.html#story1

Jim

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

Date: Mon, 21 Jun 1999 08:34:41 -0700 (PDT) From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Computer Security", Dieter Gollmann

BKCOMPSC.RVW 990430

"Computer Security", Dieter Gollmann, 1999, 0-471-97844-2 %A Dieter Gollmann %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 1999 %G 0-471-97844-2 %I John Wiley & Sons, Inc. %O 416-236-4433 fax: 416-236-4448 rlangloi@wiley.com %P 320 p. %T "Computer Security"

Gollmann is fairly explicit in stating the intention and audience for the book. It is to be a text for a course, rather than a handbook, encyclopedia, or history. It is about computer security, rather than information security in general, although there are sections on computer network security and database security. The objective of the course for which it was prepared is to give students a sufficient background to evaluate security products, rather than to address issues of policy or risk analysis. Thus the emphasis is on technical, rather than managerial, aspects.

Part one lays the basic foundation for computer security. Chapter one outlines the fundamental vocabulary and concepts. Authentication is reviewed in chapter two. Examples from both UNIX and NT are used, in chapter three, to explain access control. Chapter four's discussion of security models requires a significant background in set theory, but for a course this can be assumed as a prerequisite. Considerations for hardware or operating system level security are looked at in chapter five.

Part two examines security in the real world. Chapter six provides a good review of the UNIX security functions. Security aspects of NT are described in chapter seven, but the effective interaction of rights and permissions is not clear (a failing shared by most NT security texts). A variety of ways in which security has failed are detailed in chapter eight. This concludes with a section on computer viruses in quite different format and level of detail. The reason for this is not made clear, but I am willing to grant that most security texts do not treat the subject as well. Chapter nine talks about the evaluation of security products, but concentrates on the formal criteria laid down by governmental agencies.

Part three looks at distributed systems. Chapter ten reviews specific systems, such as Kerberos and CORBA (Common Object Request Broker Architecture) security. Specific known Web vulnerabilities are effectively used to illustrate classes of threats in chapter eleven. The explanation of cryptography in chapter twelve is nicely balanced for mechanics; a full description without a morass of detail; but is somewhat weaker on key management and cryptographic strength. Network security, in chapter thirteen, deals with implementation level topics such as the IPSec (Internet Prototcol Security) protocols and firewalls.

Part four deals with other aspects of security theory, primarily related to databases. Chapter fourteen and fifteen, respectively, discuss basic and advanced database security concepts. Problems of concurrent access, with applications in transaction processing, are examined in chapter sixteen. Security concerns of the object-oriented paradigm are raised in chapter seventeen.

In terms of readability, Gollmann's writing is not always fluid, but it is always clear. While intended as a class text, the book is, in most parts, accessible to any intelligent reader. The exercises provided at the end of each chapter are not mere buzzword tests, although most are more suitable for discussion starters than checks for understanding.

The bibliography is not annotated, but the "Further Reading" section at the end of each chapter helps make up for this shortcoming. Having to flip between two sections to find the referenced work is a bit awkward, but not unduly so.

This is a very welcome addition to the general computer security bookshelf.

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

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

Date: Tue, 22 Jun 1999 08:37:10 -0800 From: "Rob Slade" <rslade@sprint.ca> Subject: REVIEW: "Securing Java", Gary McGraw/Edward W. Felten

BKSECJAV.RVW 990501

"Securing Java", Gary McGraw/Edward W. Felten, 1999, 0-471-31952-X, U$34.99/C$54.50 %A Gary McGraw gem@rstcorp.com %A Edward W. Felten felten@cs.princeton.edu %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 1999 %G 0-471-31952-X %I John Wiley & Sons, Inc. %O U$34.99/C$54.50 416-236-4433 fax: 416-236-4448 rlangloi@wiley.com %P 324 p. %T "Securing Java: Getting Down to Business with Mobile Code"

Unlike Oaks "Java Security" (cf. BKJAVASC.RVW), this book concentrates on Java in the popular perception: as a means of providing active code on the Web. As such it is intended not simply for techies, but also for dedicated users.

Chapter one provides a readily accessible backgrounder, covering portability, the Internet, the Web, active content, security risks, other active content systems, and a rough outline of the Java security model with particular regard to applets. The original Java applet security model, or "sandbox," is covered in chapter two. The security model is now complicated by signed code, and chapter three points out the changes made. Chapter four outlines a number of malicious applets, but also gives clear directions for disabling Java on both the Netscape and Internet Explorer browsers. The authors outline a second class of hostile applets, in chapter five, that are intended to breach system security and allow an attack to bypass normal security mechanisms. There are suggestions for improving the security model, as well as a review of third party attempts to enhance it, in chapter six. (I was amused to see the slight lifting of the skirts of ICSA [International Computer Security Association]: the history of the outfit is a lot more interesting and convoluted even than is portrayed here.) Chapter seven is directed at programmers, but the advice provided looks at practices and policies rather than APIs (Applications Programming Interfaces) and chunks of sample code. A version of Java specifically designed for Smart Cards is available, and chapter eight looks at its promises and problems. A recap and restatement of the major security issues in mobile code is given in chapter nine. Appendices provide a Java security FAQ, security resource pointers, and directions on Java code signing.

The text is quite readable. The authors have made a very serious attempt to ensure that the book does not depend upon previous technical background. For the most part, they have succeeded. The diligent reader would be able to understand most of the concepts as presented, even without having worked with computers or computer security. However, the key word is "diligent:" it *feels* like a technical book, and newcomers to the topic may be put off by the style.

In addition, McGraw and Felten are careful to avoid any bias. They obviously feel that Java has some worthwhile security measures, but admit to its faults and point out its shortcomings. This makes the book extremely useful: much more so than an uncritical paean of praise.

An effective book on an important subject with a wide audience. But you don't have to take my word for it. You can try before you buy. The www.securingjava.com site does not simply contain a few press releases and the errata, but has the whole text of the book online. A bold step. (You can help justify it by then buying the book.)

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

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

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.47 ************************