The RISKS Digest
Volume 17 Issue 39

Monday, 16th October 1995

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Ambulance Dispatch System
Rohan Baxter
Presidential Black Hawk Crash
Craig J. Coley
The Johnson Bug - IBM
Jason Fleischer
How to derail a train
Bob Frankston
Basic Flaws in Internet Security
David Wittenberg
Pinging the vacuum tubes
Paul Wernick
Risks in Java
Prentiss Riddle
Effective use of the Internet
Richard Sexton
Risk of visiting wrong place on the Web
Marc Rotenberg
Another example of poor use of databases
Mathew
Analysis of Human Factors and Outages
John Mainwaring
RSI Risk/Editor Correlation (Become a statistic!)
Rudi Cilibrasi
Re: Microsoft Excel 1.40737488355328
Francois Grieu
Marv Schaefer
Joe Birsa
John Lane
Info on RISKS (comp.risks)

Ambulance Dispatch System

Rohan Baxter <rohan@cs.monash.edu.au>
Tue, 17 Oct 1995 08:55:35 +1000 (EST)

A new computerised dispatch system for the Metropolitan Ambulance Service (MAS) (Melbourne, Victoria) has run into some difficulties. According to a
report in `The Age' newspaper by Thom Cookes (17/10,p.35), an independent consultant's report identified more than fifty faults labelled `critical' or `high priority'. The dispatch system is now operating with some of the
faults still outstanding.

The system's supplier, Intergraph, has installed more than 160 similar systems around the world. However, it is the first time that the company has supplied both system and staff. It is believed that this may have resulted in less scrutiny being applied to any reported faults.

The outstanding problems are believed to be with:

  1. Automatic Vehicle Location, which uses satellites to keep track of ambulances. Too much information is causing the system to `bog down' and report incorrect locations.
  2. Automatic route recommendation, which suggests the best way for an ambulance to get to an incident. No statistical tests have been applied. However on simple tasks, the system recommended routes heading in the opposite direction from the accident scene.
  3. Allocating a vehicle to a job can take up to two minutes, during which the console is `locked up'.
Intergraph has argued that any faults in the system would show up in the log files generated daily and provided to the MAS and government. However the consultant's report flagged the report generator as also containing critical faults. In particular, the system does not accurately time how long it takes to respond to a call. Responses taking longer than 16 minutes are meant to generate an exception report. A test, where the response time was 25 minutes, straddling the time from before midnight till after midnight, didn't generate an exception.

It appears that one of the difficulties with identifying and rectifying the system faults has been their use in a game of political football between government (who has cut costs by using Intergraph), Intergraph (who is about to provide similar systems for fire and police), the Ambulance Union (who prefers its own members to do the dispatching, rather than non-paramedic civilians), and MAS management (caught between the other three). Its hard to tell what is what!

Rohan Baxter, rohan@cs.monash.edu.au ph. +61 3 905 5721
Dept. of Computer Science, Monash University, Clayton, 3168, Australia.

Presidential Black Hawk Crash

Craig J. Coley <craigc@airmail.net>
Fri, 13 Oct 1995 22:29:02 -0500 (CDT)

A Tragic Crash of a Presidential Helicopter or a Marine Corps Cover Up?
By C.J. Coley

On May 19, 1993, an unusual crash occurred in southern Maryland. What made this crash unusual was not the loss of a military helicopter and four dedicated Marines but the fact that the helicopter was part of the Presidential 'White Top' fleet and the crewmen may have perished in a most unusual way.

The first person on the scene was Frank C. Owens, a civilian who saw the wreckage while driving home from an archaeological dig. He immediately rushed to the site to render aid to any survivors. "I couldn't believe what I saw," said Owens. "Those men were burned and there was almost no bleeding from their wounds." Owens went on to describe the grizzly sight in the mangled wreckage. "What got me was there was fuel everywhere but no evidence of a fire. Their uniforms weren't even burned. But the men sure were." What Owens saw in the woods that day ultimately launched him on his own investigation to find out what really happened.

The official Marine Corps Judge Advocate General (JAG) investigation blamed the crash on an improperly installed 'roll pin' by maintenance personnel at HMX-1 in Quantico, Virginia, but Owens didn't believe this explanation. "Experts I talked to said this particular part would have failed almost
immediately after installation yet the helicopter had flown over fifteen hours since the repair. It even flew President Clinton from the White House to the U.S.S. Theodore Roosevelt. Besides, I don't know how they could have come to any realistic conclusions without all of the evidence," Owens said as he pointed to a display case containing over a thousand pieces of the wreckage collected at the crash site more than a week after the incident. "They certainly didn't follow normal investigative procedures," he said.

Owens believes that there may be another explanation as to the cause of the crash. Owens discovered that the Sikorsky UH-60 Black Hawk has a long history of Electromagnetic Interference (EMI) problems. Apparently, a number of these helicopters were lost in the 1980's after flying too close to microwave or broadcast towers. The Army tried to deny there was a problem for years but was ultimately forced to retrofit their helicopters to correct the problem. Owens went on to say he believes an Army research facility just four miles from the crash site has been working on a high power microwave system as part of the former Star Wars program. He believes that this microwave directed energy or 'beam' weapon may have been responsible for the crash. "It just fits," said Owens. "The crash fits the profile of the Army EMI problem. Most of them were flying below 1000 feet when they passed a tower and just nosed in. It's also the only way I can explain the burns suffered by the crewmen without damage to their clothing."

Owens' conclusions have been met with considerable resistance by Marine Corps officials at HMX-1. He was even questioned by Naval Investigative Service (NIS) agents who came to his White Plains, Maryland home early one Sunday morning. In addition, orders have been reportedly issued by the Marine Corps forbidding any further contact with Mr. Owens. But Owens vows to continue his investigation. "Those men had wives and children and I just can't let it go until something is resolved," he said.

In reality, the real truth may never be known. Marine Corps officials continue to deny Owens' allegations and the helicopter wreckage has now been removed from the Marine Corps inventory. In addition, many of the records, including critical autopsy photographs have been destroyed even though there is pending law suit by the families of the deceased crew members.


The Johnson Bug - IBM

Jason Fleischer <jf471003@lance.colostate.edu>
Mon, 16 Oct 1995 06:37:24 -0700

[Via Mike Crawford <crawford@scipp.ucsc.edu>]

A question to any IBM people or others who remember this-

This is a bit of campus folklore from here at CSU, and I wanted to see if anyone could provide verification for it. The story goes thus:

Several years ago a Colorado State professor of Mech Engr named Gerry Johnson goes to an IBM networking exposition. At this expo IBM is demonstrating some kind of new networking software to link PCs to the IBM global network. Dr. Johnson being the savvy controls engineer that he is asks for a demonstration of an unusual kind. He knows that the software will work in normal parameters, so he asks for something only an idiot would. He has the demo guy try to transfer a 50MB file from a 370 a few miles away. The catch is the PC has only a 20MB drive. Dr. J's argument is that if the software is written properly it will error out and say what's wrong. So they start the transfer and *poof* down goes the PC and the 370. The demo guy is apologetic and asks Dr. J. to come back tomorrow, and he'll see if he can get them to fix the problem overnight. The next day Johnson comes back to find the display boarded up. A note says that the booth is closed due to technical problems. Later that day Johnson finds out why. Not only did the 370 and the local PC go down, IBM'S ENTIRE GLOBAL NETWORK BIT THE DUST! Every computer attached to it went off-line. Months later, it turns out that it wasn't the new networking software as they had expected, but a bit of code in the 370 MVS operating system that had never been executed in the entire 15yrs or so that it had been in existence up to that date.

According to the story around campus, this is a fairly (in)famous incident in IBM history. I would like to know if anyone out there knows anything about it. How about IBM's viewpoint on it? I'd really like to know how much of this is fact.

And, if no one knows anything, I hope it was at least amusing to read :)

Jason Fleischer jf471003@longs.lance.colostate.edu

How to derail a train

<Bob_Frankston@frankston.com>
Fri, 13 Oct 1995 07:56 -0400

I was surprised to see TV news stories and front page articles giving instructions on how to derail a train from which bolts to remove to how to defeat the electronic system checks. In today's news, there is some suspicion that the sabotage was inspired by a recent article giving the details and, in effect the instructions, on how to derail a train. It was a story, in a limited circulation railroad magazine, describing a 50 year old crash that, apparently, was printed a week ago.

This is reminiscent of the controversy over Internet security alerts, though this doesn't necessarily argue for keeping the details secret. In the case of the train, however, I was surprised how public the instructions were made.


Basic Flaws in Internet Security

David Wittenberg <dkw@cs.brandeis.edu>
Thu, 12 Oct 1995 16:44:14 -0400 (EDT)

Eric Brewer, Paul Gauthier, Ian Goldberg, and David Wagner have published an attack on most of the "secure" internet protocols. The trick is to spoof NFS to provide corrupted code to the NFS client which runs the code. They have demonstrated that their attack works against Netscape and Kerberos.

The New York Times had a page 1 article on this on 11 Oct.

The original article, which includes a pointer to the article in the The New York Times, is available at http://http.cs.berkeley.edu/~gauthier/endpoint-security.html

--David Wittenberg dkw@cs.brandeis.edu

Pinging the vacuum tubes (Re: Univac episode, Williams, RISKS-17.38)

<Paul.Wernick@cl.cam.ac.uk>
Fri, 13 Oct 1995 11:25:52 +0100

I have been told that, in the early vacuum-tube days of computing, it was the responsibility of one of the lower-order acolytes to go round the vacuum tubes on the system and `ping' each one. A `pong' meant that the tube had failed or was about to fail, and it was replaced before the machine was started. How can we perform such preventive maintenance nowadays - are there any systems which inform us of when they might be about to go wrong, other than by having multiple instances of the hardware and reporting disagreements? What is the equivalent of the `ping' test for small components?

The RISK? - implicit in any system that will tell you that it's _going_ wrong only when it's _gone_ wrong, like all of those dinky bits of plastic-covered silicon with legs!

Paul Wernick

Risks in Java

Prentiss Riddle <riddle@is.rice.edu>
Fri, 29 Sep 1995 12:38:51 -0500 (CDT)

BACKGROUND: Java is a language for writing procedural objects known as "applets", intended to be distributed on the World-Wide Web as easily as
HTML is distributed today. Netscape Communications Corp. has announced the impending release of a beta version of Netscape 2.0 to include support for Java. For more information, see:

http://java.sun.com
http://home.netscape.com/comprod/products/navigator/version_2.0

RISKS: On its face, Java violates the security principle that one should minimize the execution of untrusted software. On a Java-enhanced web, every click of the mouse in one's web browser could download and execute software about which one knows little or nothing. The designers of Java say that they have paid a great deal of attention to Java's security environment, and they are confident that Java is immune to viruses. This claim may be true, but it does not address the issue of trojan horses. Even if Java applets have access only to local resources which have been explicitly authorized by the user, the risk of trojans remains. It seems to me that it is impossible to grant an untrusted program useful access to resources without granting it the opportunity to *misuse* those resources.

Furthermore, since one of the resources to which Java may often require access is the network itself, a trojan written in Java might carry out all sorts of mischief without touching the local disk: consider a Java applet which does something useful or entertaining while surreptitiously spamming targeted mailing lists or newsgroups with, let's say, racist hate mail. I'm sure others can think of nastier examples.

None of these risks are new with Java, but widespread use of Java promises to change the risky event of running untrusted software from something the average Internet user does occasionally to something the average Internet user does every time s/he visits a new web page.

META-RISKS: I have posted these concerns to a variety of forums in the past weeks (including comp.security.misc and the hotjava-interest and www-security mailing lists). I have yet to see any satisfying discussion of whether or not the impending widespread deployment of Java-capable web browsers constitutes a serious risk, or whether responsible system administrators should permit the installation of Netscape 2.0 on their systems.

Part of the problem seems to be that most everyone who really knows much about Java had a hand in developing or testing it and is committed to its success. Part of the problem also seems to be a sense of inevitability, that Java and Java-capable Netscape are much too attractive for their developers to consider not releasing them or for users to consider not using them once they are available. It may turn out to be the case that Java's benefits outweigh its risks, but the Internet community appears to be incapable of considering its risks and benefits in advance. There's nothing new about technological determinism, but Java seems to be a fairly clear case in miniature.

-- Prentiss Riddle riddle@rice.edu
-- RiceInfo Administrator, Rice University / http://is.rice.edu/~riddle
[See also an earlier item on this topic by Joe Smith in RISKS-17.01. PGN]

Effective use of the Internet

Richard Sexton <richard@interlog.com>
11 Oct 1995 17:07:59 -0400

I got a letter from a company in South Carolina flogging a publication they wrote claiming this report will help me to make effective use of the Internet.

Actually I got 22 of them so far. Addressed to such organizations as:

"The Ontario Mango Growers Cooperative".
"The Toronto Cabal"
"The Sexton Clan"
"The Society for preservation of god under windows"

In other words, the organization line of domain registrations I own for mango.net, cabal.org, sexton.org and godwin.com,respectively.

The irony of this "effectiveness" is not lost on me. They spent over $US10 in postage to try to get my to buy their $300 report so I can use the Internet as effectively as they do.

I called them to register my irony — decidely not to complain. Nobody could talk to me, but I could leave a message. I asked if I could leave an E-mail address, they said sure, and took it down. The person on the phone, in the customer service department, however, didn't have a clue what an E-mail address was, the "@" and "." confused them terribly until I took 5 minutes to explain what an E-mail address looked like.

Jane, get me off this crazy thing.

Richard Sexton richard@cabal.org There is no Cabal

Risk of visiting wrong place on the Web

Marc Rotenberg <rotenberg@epic.org>
Sun, 15 Oct 1995 18:44:44 -0400 (EDT)

The Marketry company of Bellevue, Washington is now selling E-mail addresses of Internet users obtained from Newsgroup postings. From the company's press release:

"These are E-mail address of individuals who are actively using the Internet to obtain and transfer information. They have demonstrated a substantial interest in specific area of information on the Internet. They are regularly accessing information in their interest areas from newsgroups, Internet chats and websites. . . . The file is anticipated to grow at the rate of 250,000 E-Mail addresses per month, all with Interest selections."

What are the interest areas currently available? "Adult, Computer, Sports, Science, Education, News, Investor, Games, Entertainment Religion, Pets." The release notes that "additional interests areas will be added, please inquire." Activities of US and non-US Net users will be included in the Marketry product.

*The Washington Post* reported that the president of Marketry, Norm Swent,
would not disclose who the actual owner of the list is. "That really is confidential information," Swent said, "and we are obviously bound by confidentiality agreements with the list owner."

WHAT YOU CAN DO:

(a) Sit back, let your newsgroup postings get swept up by the data scavengers and watch the junk E-mail pile high on your system, or

(b) Send E-mail to Marketry and tell them to STOP SELLING PERSONAL DATA GATHERED FROM THE NET. Send E-mail to: listpeople@marketry.com and tell your friends to send E-mail. And tell your friends' friends.

It's your name. It's your mailbox. Think about it.


Another example of poor use of databases

mathew <meta@harlequin.co.uk>
Tue, 10 Oct 1995 11:09:07 +0100

From the Electronic Telegraph <http://www.telegraph.co.uk/>, 1995-10-10:

Victim of gas blast sent 3230 pound bill (=A3230), by David Graves

BRITISH Gas apologised yesterday for sending a bill to a man who died in an explosion at his home caused by a suspected gas leak. The invoice, addressed to "Mr J Clark - Deceased", was sent last month to John Clark, 36, a father of two, who died when the explosion demolished a block of flats in Ilkeston, Derbyshire, in July. [...] The bills, collected by Miss Hill from a local Post Office sorting office, were also addressed to Mr Clark's flat, which was destroyed in the explosion. [...] A British Gas spokesman said a "billing error" had allowed the bills to "slip through the net. "We made arrangements to put a block on all accounts affected by the explosion but, unfortunately, due to an administrative error, these invoices were accidentally sent to Mr Clark. We have launched an investigation."

mathew http://www.domino.org/~meta/

Analysis of Human Factors and Outages

j.g. <"john>
Fri, 13 Oct 1995 10:15:00 -0400

Long-time readers of RISKS may be interested to hear of an initiative by Bellcore that would address some stories that have appeared here.

The Bellcore Digest for Aug/Sept 95 announces that document GR-2914-CORE is due to be published in Dec 95. The Digest says that extensive analysis of field reports have identified patterns of procedural error that could be attributed to design characteristics of maintenance user interfaces of many elements of the telephone network. GR-2914 will contain requirements intended to improve and standardize maintenance user interfaces of any piece of network equipment.


RSI Risk/Editor Correlation (Become a statistic!)

Rudi Cilibrasi <cilibrar@sloth.ugcs.caltech.edu>
14 Oct 1995 07:41:30 GMT

I've recently wondered whether the default keymappings of various popular Unix editors might be risk factors in getting Repetitive Strain Injury.

To investigate this question, I've created a WWW-based survey program at http://rmachine.caltech.edu/~www/rsisurv.cgi

If you have a forms-capable web browser, and have about two spare minutes, I'd appreciate it if you'd take the time to fill out this simple survey. I will post a summary of results, if any.

Thanks for your help,

-Rudi Cilibrasi

Re: Microsoft Excel 1.40737488355328

Francois Grieu <fgrieu@micronet.fr>
Fri, 13 Oct 1995 16:19:49 +0100

Enter 1.40737488355328 in an Excel cell.

Appears 0.64

This is reproducible in version 4.0 or 5.0, under Windows and Macintosh OS. Seen on 486, Pentium, 68040, PowerPC 601 processors. Also reported in Excel version 7 under Win 95.

Now, more details on the problem.

It shows for at least the following 3 numbers, and their negative
1.40737488355328 2.81474976710656 5.62949953421312

Also happens in scientific notation, e.g.
140737488355328E-14 281474976710656E-14 562949953421312E-14

Mathematically these numbers are really
2^47 / 10^14 2^48 / 10^14 2^49 / 10^14

In my configuration the bug does not show VISUALLY in a cell
containing =1.40737488355328 or = 2^47 / 10^14 .
Still, such a cell has something badly wrong: taking it's integer part gives 0 instead of 1. That is, =INT(2^48/10^14) gives 0.

It appears to be a bug, not a deliberate signature of the code as suggested in RISKS DIGEST 17.38.

The fact that the numbers triggering the bug have a simple mathematical form make them immensely more likely to appear in an Excel cell than if it was for a few arbitrary values. Still, the spread of the bug by Internet is an even more decisive factor ;-)

Microsoft is rumored to acknowledge the problem and have/prepare a fix. Still, I failed to find any info on this in the Microsoft Knowledge Base on Excel, at http://www.microsoft.com/kb/indexes/excel.htm

Quoting Michael J. Lindsay (lindsay@azstarnet.com):
" This was discovered by Stuart Worley of Hughes Aircraft Company, Tucson
AZ when he input the following formula in a large spreadsheet on September 11, 1995 : +INT((2^47)/(10^INT(LOG(2^47)))) The result 0 instead of 1 stood out of the middle of the spreadsheet. This prompted him to investigate further. "

Francois Grieu
[Also noted by Mark Brader <msb@sq.com>, who pointed at <http://www.microsoft.com/msoffice/xler0925.htm>, the text of which was also posted recently to comp.apps.spreadsheets, comp.bugs.misc, and comp.arch.arithmetic by Michael J. Lindsay (lindsay@azstarnet.com). There were many other messages on this subject as well. I have sampled just a few. PGN]

Re: Microsoft Excel 1.40737488355328

Marv Schaefer <marv@md.arca.com>
Mon, 16 Oct 1995 13:38:09 -0700

> Interestingly enough., Excel v5.0a on a Mac IIsi also yields .64; however,
> if you paste the original number as text and then perform a math operation,
> Excel yields the correct result.

Curiouser and curiouser. Not only does 1.40737488355328 get correctly entered if pasted in place on my MAC PowerPC 6100 in Excel v5.0a, it also is correct if entered manually as a computation (i.e., as '=1.40737488355328'). The boundary values (viz, 1.40737488355327 and 1.40737488355329) are correctly treated in computation and in "Regular" display sans the '=' symbol. 1.40737488355328 becomes 1.28 if typed in directly, though.

It certainly does look like PGN's suggested special case for copyright protection....

Marv

Re: Microsoft Excel 1.40737488355328

"Joe J. Birsa E-375B 8-284-5192" <birsaj@h01.pgh.wec.com>
Tue, 10 Oct 1995 14:29:18 -0400 (EDT)

Map companies also seem to put intentional errors on their maps to detect copyright infringement. One error on a Pittsburgh street map would have had drivers going down steps on a hillside where a street ended at the top of a set of municipal steps. Since this was not corrected on the map for many years, I suspect that it was intentional. Usually, this type of error is limited to insignificant streets and roads; insignificant, that is, if you never have to travel on them.

Your suspicion that the spreadsheet error was intentional may well be not unfounded.

Joe Birsa birsaj@h01.pgh.wec.com

Re: Microsoft Excel 1.40737488355328

John Lane <PSCLANE@ubvms.cc.buffalo.edu>
Thu, 12 Oct 1995 11:50:20 -0400 (EDT)

>[I have heard some reports that this flaw is actually an intentional
>feature intended to detect copyright ripoffs.... PGN]

I have my doubts about that. When the publishers of "Who's Who" put in a handful of fake biographical entries, they want to catch anyone who presents the contents of "Who's Who" as their own research in, say, a rival dictionary or a mailing list.

But Microsoft's great problem is the selling of pirated copies of their software packages. The pirates want to present their copy not as their own work but as the original product, feature for feature. A copied mistake adds to the air of authenticity.

John Lane

Please report problems with the web pages to the maintainer

x
Top