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…
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.
Quoted from NASA Press Release 95-203:
ICE CAUSE OF X-31 CRASH
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 acfa@eci-esyst.com[Also noted by Philip R. Moyer <prm@rome.isl.sri.com>. PGN]
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)
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)
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 - mike@pires.co.uk - +44 (0)1223 441 256The 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,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% safe...you 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.
PGIn 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 beatty@netcom.com beatty@ibmoto.com[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]
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,[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]
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]
This response was recently posted to comp.lang.java. Marianne Mueller <mrm@eng.sun.com>, Java Products Group, Sun Microsystems, Inc.
Article 4356 of comp.lang.java:
Path: handler.Eng.Sun.COM!puffin.Eng.Sun.COM!mrm
>From: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
Newsgroups: comp.lang.java
Subject: Re: PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE
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
So, JDK beta applets (and Netscape 2.0beta applets) may not do the following.
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
Applets cannot
Applets cannot
Applets cannot
alpha3 HotJava JDK ---------------------- ---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.
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.
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 http://java.sun.com/people/mrm/Please report problems with the web pages to the maintainer