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 17 Issue 45

Monday 13 November 1995


o Risks of your moderator being off-line
o Ice Cause of X-31 Crash
Andy Fuller
o RSA Wants License for Digital Signature Technology
o Espionage charges dropped against Kevin Poulson
o Demon Internet: A "demon"?
Mike Ellims
o Re: Traffic Signaling Problems in Chicago Train/Bus Crash
Clive D.W. Feather
o Re: Making Railroad Crossings Safe
Paul Green
o Re: Writing solid code
Derek Lee Beatty
o Another surname-extraction bug
John Gilliver
o Faster computers will never make security safer!
Jacob Palme
o Regarding Java security
Marianne Mueller
o ABRIDGED info on RISKS (comp.risks)

Risks of your moderator being off-line

"Peter G. Neumann" <>
Mon, 13 Nov 95 08:01:36 PST

For those of you who wonder about the irregularity of RISKS issues, you must realize that RISKS appears whenever two things happen: (1) there is *good* material, and (2) I have a few spare moments to put out an issue. The past year has been one with me having many diverse activities coupled with the fact that noteworthy risk manifestations continue to occur.

For the RISKS record, here are a few cases noted over the past few days.


Ice Cause of X-31 Crash

Andy Fuller <>
Thu, 9 Nov 95 10:27:43 EST

Quoted from NASA Press Release 95-203:


A Mishap Investigation Board studying the cause of the X-31 experimental aircraft accident on January 19, 1995, has concluded that an accumulation of ice in or on the unheated pitot-static system of the aircraft provided false airspeed information to the flight control computers, causing the aircraft to go out of control and crash.

It is apparent to me that this crash is the result of a bug in the flight control software and sensor hardware of the X-31 aircraft. The computer was unable to compensate for a loss of the airspeed indicator.

The pitot tube is used to measure airspeed. Icing of this probe is a common problem familiar to all pilots. BUT IT IS NOT NECESSARILY FAMILIAR TO SOFTWARE ENGINEERS. A pilot can still fly a conventional aircraft if he loses his airspeed indicator. He checks the airspeed once in a while, and can intuitively tell if it has failed (a reading of zero is pretty impossible while the aircraft is flying). The flight control computer was apparently unable to sense the failure of the airspeed indication, and thus acted as though the aircraft was travelling very slowly. This is the equivalent of driving a car on the highway, but steering as though in a parking lot.

The X-31 is a "fly-by-wire" aircraft that is inherently unstable. A computer between the pilot's controls and the flight control surfaces is necessary for the aircraft to fly.

The amount of control surface movement is inversely proportional to the airspeed: at high airspeed a small movement is sufficient to keep the aircraft under control, at low airspeeds more movement is necessary to provide the same correcting force. If the aircraft is travelling fast, but the computer senses a low airspeed, it will over-control.

The RISKS? A computer's view of a flying environment is very different from the pilot's. The computer relies on a very small number of data sources (it has no eyes, ears, or "seat of the pants"). People who control aircraft, cars, ships, trains, power plants, etc. use lots of information that is unavailable to a computer doing the same task. We need to understand these differences before we use computers to take over the job of a human.

Andrew C. Fuller, E-Systems, ECI Div., Box 12248, St. Petersburg, FL 33733 (813)381-2000 x3194 Fax:(813)381-3329
[Also noted by Philip R. Moyer <>. PGN]

RSA Wants License for Digital Signature Technology (Edupage, 12 Nov 1995)

Educom <>
Sun, 12 Nov 1995 23:30:22 -0500 (EST)

RSA Data Security claims it owns the dominant patent covering digital signature technology, and wants other companies and government agencies to pay them license fees for using it. The U.S. government is fighting RSA's claim, saying the digital signature algorithm it uses in its digital signature standard is covered by a different patent. If RSA can make its claim stick, the government will owe the encryption company royalties for use of its digital signature standard. (Information Week 13 Nov 95 p20)

Espionage charges dropped against Kevin Poulson (Edupage, 12 Nov 1995)

Educom <>
Sun, 12 Nov 1995 23:30:22 -0500 (EST)

Federal prosecutors have decided to drop espionage charges against computer programmer Kevin L. Poulson because the military document in his possession was obsolete, he was lawfully entitled to access it, and he had not shared it with anyone else. In exchange for the dropped charges, Mr. Poulson pleaded guilty to unrelated crimes involving illegal access into files of the Pacific Bell Telephone Company. (New York Times 12 Nov 95 p18)

Internet Demon: A "demon"?

Mike Ellims <>
Fri, 10 Nov 95 16:22:36 GMT

Anger over e-mail jam By Richard Grant [Excerpted from an unspecified British Sunday paper a week or two ago]

BRITAIN'S biggest Internet service provider has been attacked by furious customers after 60,000 electronic mail messages went astray or were delayed. Fast growing Demon Internet was valued at 26.7 million (pounds) last week in a City fund-raising exercise backed by venture capitalist Apax Partners. Yet at the same time it was advising some of its clients with the right equipment to by-pass its mail relay service to avoid electronic traffic jams. Angry Demon customers also reported e-mail messages becoming lost or being bounced back to them after trying to send them after trying to send them across the Internet though Demon's electronic gateway. Some said they would quit Demon as they had lost confidence in its service. Many of the delayed messages, which are transmitted from computer to computer across continents for the price of a local phone call, have taken up to five days to arrive. The industry standard is under 60 minutes. ... Demon's Todd said: 'When you double in size every five months things don't degrade gracefully, they suddenly go bang catastrophically'. ...

What I find amusing is that the company I work for uses Demon as its service provider. If your reading this then the mail got though! We have recently been getting mail messages that have been bumping around in the guts of the system (Demon Internet)for up to a month. I myself have been getting a lack of response to mail message I've been sending out but I expect that because no-one wants to talk to me :-) Other people have performed experiments where they mail each other and third parties, the third parties received the mail but it was not seen here.

This seems like a good example of things not scaling up well.

Actually something that happened moments before I was about to send this is that I have just re-received a mail message sent to me 2 weeks ago.

The views expressed here and the fact I've copied something from a newspaper source are my own doing and do not reflect the views of my employer or my cat. Also all spelling errors are due to the cat playing on the keyboard.

Mike Ellims - Pi Technology - - +44 (0)1223 441 256

Re: Traffic Signaling Problems in Chicago Train/Bus Crash

"Clive D.W. Feather" <>
Fri, 10 Nov 1995 15:44:54 +0000 (GMT)

The UK has a simple and elegant solution to this. There is a standard road marking - a diagonal yellow grid - which means "do not enter this area unless your exit is clear" [there are exceptions to the rule, but they don't apply at rail crossings]. This is then painted on the road at *every* automatic rail crossing.

In addition, if there is a significant chance of traffic backing up over the railway, the crossing *must* have gates or barriers completely blocking the road, and is operated by a person who must positively verify that the track is clear before the rail signals can change from Danger. In most modern installations, remote control with CCTV is used.

Clive D.W. Feather, Demon Internet Ltd. Gateway House, 322 Regents Park Road,
Finchley, London N3 2QQ Tel: +44 181 371 1000

Re: Making Railroad Crossings Safe

Thu, 9 Nov 95 14:05 EST

I've been thinking about the Fox River Grove (Chicago) train/school bus accident. I think we have to be careful how we define the problem we are trying to solve.

Are we trying to make grade-level railroad crossings safe? Are we trying to make grade-level railroad crossings that are exceptionally close to a traffic light safe?

If this is the problem definition I'm not sure it can be solved in a way that is completely safe and cost-effective. Any signalling mechanism is eventually going to fail, or be ignored, or be rendered unsafe by changes in weather, train weight, speed, or traffic light timings. 99.999...9% safe is not the same as 100% safe.

What if we defined the problem instead as trying to eliminate collisions between railroad trains and other objects (automobiles, bicycles, pedestrians, etc.)?

This past summer I had the pleasure of traveling from Gare du Nord in Paris to Waterloo Station in London on the new Eurostar train. One of the things that only gradually dawned on me is that there are ZERO grade-level crossings for the entire journey. I'm going from my memory and observations, which, of course, are subject to error, but I don't remember seeing any streets, trails, or footpaths where an auto, bicycle, or pedestrian could have come in contact with the train.

Lest anyone observe that Fox River Grove is pretty flat (I grew up near there) and so it would be expensive to elevate or depress either the railroad right-of-way or the highways, I would point out that most of northern France and southeast England is also pretty flat. That didn't stop the builders of those lines from constructing an elevated embankment for the railroad line, and running the streets and highways under it.

Can the Eurostar strike an object? Sure. It passes thru stations, railroad yards, and switching areas where trespassers, employees, or passengers can walk or fall onto the tracks. But I think it is safe to say that a Fox River Grove type of accident will not befall the Eurostar any time soon.

I find myself heading towards an economic argument. Sometimes (not all the time), improving safety raises the costs. Should the good people of Fox River Grove be told that their children gave their lives so that they could have cheaper train tickets? Or did they think that a simple set of relays, lights, and timers would be 100% reliable, and so they could both be safe and save money? Or should we have told them, "This intersection is 99% supply the last 1% with your own actions?"

I grew up in Elgin, Illinois, which has many active railroad crossings, at grade level, over busy streets. My father taught me to *never* stop the car on the tracks, *no matter* whether there were automatic gates, flashing lights, or "cross bucks". Most people know that trains cannot stop in time. Why is a school bus driver stopping a bus with the last 3 feet hanging over the tracks, and, if that was unknown to her, why is a person driving a bus that she is not totally familiar with?

As a guess, we seem to have an inherently dangerous crossing, reliance on an imperfectable signalling system, a driver unfamiliar with the route, a driver unfamiliar with the bus itself, and a train that just happens to come along at the key moment. That's 5 (not necessarily rare) events. It makes me ill just to think about it.


Re: Writing solid code (Gong, RISKS 17.44)

Derek Lee Beatty <>
Fri, 10 Nov 95 21:09:46 -0500

In RISKS-17.44, Li Gong paraphrases Steve McConnell's (or is it Steve McGuire's?) Microsoft Press book, _Writing_Solid_Code_. He tacitly criticizes the book's purported advice to elide error-checking code from the ship version. Unfortunately, Mr. Gong omitted his own error-checking. His version is not what the book advises at all. The book gives some good advice: distinguish 1) code that checks for system and user errors, from 2) assertions that check for programming errors. It admonishes that (after thorough testing) the latter can be removed from the ship version for better performance, but the former must *never* be removed. This is neither new nor so entertaining to RISKS readers, but it's sound advice.

Derek Lee Beatty Austin, Texas
[Li Gong is unavailable at the moment for further comment.

For the record, a better translation of "keine bedeutenden Fehler" given by Klaus Brunnstein as "no essential bugs" in RISKS-17.43 would be "no fundamental bugs". Subtle difference. PGN]

Another surname-extraction bug

John Gilliver <>
Fri, 03 Nov 1995 12:22:41 +0000 (GMT)

I have a VISA card supplied by the Co-operative bank here (in the UK); I don't have an account with them, just that they offered a free-of-charges-for-life card, so I took it. (At the time many of our VISA card operators were implementing annual fees.)

Anyway: one feature which I liked at the time was that I could specify how my name was to appear on the card; I therefore have my degree qualification shown - "MR J P GILLIVER B SC". (I might not do that now, but anyway.)

I have now received a letter from them (selling death insurance - I'd have thought they would know I have no dependents, but never mind), from which I see that the way they implemented the name-as-I-like-it in their database is that they have stored my name as "Mr J P Gilliver B SC". (I would have preferred "J. P. Gilliver, B. Sc.,", but the data processing world seems to have a horror of any punctuation, let alone lower case letters.)

After my address, the letter starts: "Dear Mr SC". Whether this is just the result of a very dumb algorithm which just takes the last "word" in the address line as the surname, regardless, or whether the data was not entered into fields correctly, is not of course discernible; I just had a smile at it! The risks are not that obvious, though I suppose if some part of the system just extracted what it thought were surnames from the list, or for that matter sorted by what it thought were surnames, incorrect operation would ensue.

(As an aside, the genealogy software I use - Brother's Keeper 5.2 - _does_ handle suffixes properly - it recognises many standard ones, such as Jr, II, and so on [can be bypassed if that really is the surname], and I think also recognises anything with a dot in it - so it _is_ possible to correctly handle these sort of things. That's a shareware package, too!)

J. P. Gilliver, GEC-Marconi Research Centre, GEC-Marconi Ltd, GREAT BADDOW,
Essex, CM2 8HN, UK. Tel: +44 1245 473331 x 2133
[See RISKS-15.08 for an amusing collection of previous episodes from various sources, contributed by Mark Brader, and summarized in the table on page 198 of my book (Computer-Related Risks). PGN]

Faster computers will never make security safer! (Re: Kamens, 17.40)

Jacob Palme <>
Thu, 9 Nov 1995 17:29:38 +0100 (MET)

One often hears a statement, which sounds plausible as in the following quote from Jonathan Kamens in RISKS, 19 October 1995, Volume 17 Issue 40:

> An aside: I suspect that one of the reasons why integrity-protection
> and/or encryption weren't put into Kerberized NFS and AFS originally
> was that such protection significantly increases the CPU load on the
> servers and clients using it; however, CPU speeds have increased so
> much in the past few years that perhaps now we can spare the cycles to
> make our files secure.

The problem is that CPU time becomes less costly at the same ratio for the encrypter as for the encryption breaker. Thus, less cost for CPU time may not make encryption more useful.

[This is similar to Fred Brooks' Free Component Fallacy. I first ran into the FB-FCF in the 1960s, when someone at a conference suggested that memory was becoming so cheap (yes, 1960s) that ALL memory might as well be associative. Someone referred to Fred, pointing out that if associative memory were still 300 times the cost of ordinary memory, the suggestion did not make sense. But in Jacob's case, the make-or-break ratio need not grow linearly. There are some schemes for which the breaker has almost NO cost (for example, where the operating system is vulnerable to attack), and others where the breaker really has an exponentially growing difficulty. PGN]

regarding Java security

Marianne Mueller <>
Fri, 10 Nov 1995 15:45:00 -0800

This response was recently posted to Marianne Mueller <>, Java Products Group, Sun Microsystems, Inc.

Article 4356 of
Path: handler.Eng.Sun.COM!puffin.Eng.Sun.COM!mrm
>From: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
Date: 9 Nov 1995 00:50:27 GMT
Organization: Sun Microsystems, Inc. Mt. View, Ca.
Keywords: alpha3 hotjava security

The paper written by the two students at Princeton describes possible attacks on the alpha3 HotJava browser, which have all been fixed in JDK beta. Granted, until this week, the source code for JDK beta wasn't available, so it's understandable that they analyzed the alpha3 source base.

We understand people need more information on the security model, and we're taking time right now to document the security story more rigorously. A security FAQ, an updated whitepaper, detailed user documentation and detailed implementor's documentation are all being worked on.

The Java security mechanisms include:

Java language mechanisms

Browser mechanisms, used by JDK beta appletviewer and by Netscape Navigator 2.0beta The goal for JDK beta is to enable browsers to run untrusted applets in a trusted environment. The approach is to be conservative at first, and to add functionality when it can be added securely.

So, JDK beta applets (and Netscape 2.0beta applets) may not do the following.

  1. Files:

    Access Control Lists are greatly restricted in beta, as compared to the situation in the alpha3 HotJava browser. ACLs are initialized - only once - by the applet security manager, and are not user configurable.

    For a file not on the access control list, an applet cannot

    Applets cannot
  2. Sockets:

    Applets cannot

  3. Loading/linking:

    Applets cannot

  4. Process control:

    Applets cannot

  5. awt:

    Applets cannot

    Applets can use network connections only to connect to the host they originate from, to download files that are part of the applet's implementation. Those files might be java bytecode class files, or they might be input files used by the applet (GIF, JPEG, audio, other data files.)
Taking a look at the specific attacks mentioned in the paper -
alpha3 HotJava          JDK
----------------------      ---

1. socket accept() and applets cannot use
listen() aren't protected accept() and listen() adequately, allowing a browser to eavesdrop
2. applets can connect to applets cannot connect
the SMTP (mail) port on to the SMTP port on some web server and use the computer the applet that as a covert channel is visiting
3. InetAddress.getByName() applets cannot use
is public and does not InetAddress to inquire check the security mode about hosts they are before making DNS request not already allowed to connect to
4. applets can use DNS to applets may not get the
create a covert channel internet address of any host
5. Access Control Lists (ACLs) ACLs are greatly restricted
for reading and writing in JDK beta. files are not strict enough Reading/writing files is disabled for web browsers, such as Netscape Navigator 2.0.
6. applets can use the System.getenv() is obsolete
System.getenv() method and is not part of the JDK to gather information about API the computer that it is running on
7. applets can change the applets cannot read or alter
property manager database client properties
8. applets can change the The fields that hold the
HTTP and FTP proxy server HTTP and FTP proxy names are private. The values are stored in a property manager database that an applet cannot read or write.
It's very difficult, if not impossible, for a web browser to completely prevent denial of service attacks. The JDK applet API doesn't claim to prevent denial of service attacks. A "denial of service" attack is where someone writes an applet whose goal is to consume all available resources on your computer, forcing you to kill the browser you're running. For example, someone could write an applet that creates a million pop-up windows. The windows don't do anything, but creating a million of them might use up all the virtual memory on your computer and you'd have to kill the web browser to reclaim the virtual memory.

Before people engage in too much wailing and gnashing of teeth about how applets have been too severely restricted -

We want to enable applets to do interesting things, including making socket connections, and reading and writing to the file system. One way to enable that is to used a signed class loader. When a trusted applet is loaded, then the applet could be granted permission to do some of the things they are prevented from doing by default.

The goal is to ensure that untrusted applets can't steal or damage information on a computer running a Java-enabled browser. Later, we can allow trusted applets to do things that untrusted applets are not allowed to do. Since an implementation bug in a trusted applet could open a loophole that could be exploited by an untrusted applet, design matters.

Marianne Java Products Group

Please report problems with the web pages to the maintainer