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…
San Francisco has been trying for the past three years to upgrade its 911 system, but computer outages and unanswered calls remain rampant. For example, on 12 Oct 1995 the dispatch system crashed for over 30 minutes in the midst of a search for an armed suspect (who escaped). The dispatch system was installed two months ago as a temporary fix to the recurrent problems, and it too has suffered unexplained breakdowns. Screens freeze; vital information vanishes; and roughly twice a week the system crashes. Dispatchers are not able to answer between 100 and 200 calls a day. Many nonemergency calls are also being lost. [Source: article by Phillip Matier and Andrew Ross, *San Francisco Chronicle*, 18 Oct 1995, p.A1.] The reported extremely stressful working conditions seem similar to some of the air-traffic controller woes.
A power failure at 12:08pm on 17 Oct 1995 caused a 12-minute outage in the air-route traffic-control computer system, affecting traffic in parts of Texas, Oklahoma, New Mexico, Louisiana, and Arkansas. [News services. No further details.]
An article in Flight International, 11-17 October 1995, p8, entitled `DC-10 misses Frankfurt runway--by 300km', considers the aftermath.
Brussels ATC attributed the original error to the Shannon ATC controller entering an incorrect code to the ATC flight-plan data. The Irish Aviation Authority denies this, saying the correct code was passed to London ATCC, the last such ATCC before Brussels. Brussels maintains that when the aircraft got to them, the destination data had been changed. `A senior Brussels ATC official' confirms that NW52 was cleared by London ATCC as it left the London control region to descend to 24,000 ft (I think they mean Flight Level 240 but I'm not sure — I'll use FL's anyway). The aircraft's planned track for Frankfurt would have taken it over Belgium at FL370 under control of Maastricht ATCC in the Netherlands, which handles traffic over FL245 across Belgium.
NW52 also addressed Brussels as `Frankfurt' on contact, and numerous times thereafter. Brussels ATC didn't question the `addressing error', apparently. They were also cleared to a VOR, Bruno, that they didn't recognise, and asked for the frequency. They were cleared for an ILS RWY 25L approach, which is the same runway orientation as at Frankfurt, but with a different ILS frequency. NW says that the crew must share responsibility, no matter what happened with ATC (this is in any case what aviation law requires).
It looks like there is a lot for them to discuss.
Peter LadkinAn article by Brian McGrory entitled "E-mail as evidence" in *The Boston Globe*, 19 Oct 1995, p.1, (the article discusses this and also the issues about companies' right to read employee E-mail) had the following anecdote, which seems made for RISKS:
...A high-level executive with a Manhattan health company had a new technology that allows users to tape themselves with a tiny camera built into their monitor, send it through the system, and have it appear on the recipient's screen as a talking, moving image [sounds like a Connectix camera on a Macintosh to me]. One night, arriving at her hotel, she flipped open her portable computer and began recording such a message. Sitting before her laptop in the privacy of her room, she teasingly disrobed, performed what a corporate lawyer later would describe as a "shimmy," and purred to the intended recipient, a fellow married colleague, "Hurry to the hotel and here's what you get tonight." Problem is, she struck the wrong button on her computer, and the video flashed on the screens of more than 400 employees throughout her health company — subordinates, bosses and people who had never met her before."
The article goes on to describe how bootlegged copies of the message was distributed around the company, and appeared on floppy disks sold at computer fairs. [Health fairs, too, perhaps? PGN]
And I thought Oliver North had set the record for embarrassing E-mail screw-ups.
Espen Andersen <self@usa1.com>If we are going to "analyze" java security, let's keep in mind that there is an important distinction between the language (java) and the machinery which runs the java program.
Java is a general-purpose programming language along the lines of C/C++. So, there is no doubt that its expressive power overwhelms our theoretician's abilities to predict java-programs behavior — this is where we start getting into the halting problem, computability and other black magic. Basically, i don't think we can "trust" programs written in any *useful* programming language.
The area where we can (must) build trust is the computing base. Traditionally, this has been the OS, but in the case of java, it is the java interpreter (such as netscape 2.0 and hotjava). The browser is now the TCB (trusted computer base) for all practical purposes...
And, to address the specific concern about applets spamming the net — from what I've seen, applets are only allowed to connect to the server that supplied the applet in the first place (by default). The worst thing one could probably pull off is to spam oneself.
I think that before you go citing risks you out to read the Java security documents and Java mail archives first. They go into a lot of detail discussing for the the "risks" that you mention and show that they are not risks associated with running Java code. [...]
The Java enabled browser can be configured so that applets loaded from have access to the local machine or local network, applets loaded from the local net can be allowed access to the local machine or local net, applets loaded from non-local networks can denied access to the local machine or network, so no this isn't a risk.
> META-RISKS: I have posted these concerns to a variety of forums ...
Again, before you go blindly posting these messages, why don't you read the mail archives first and save everyone from having to repeat the discussion every month. [...]
Please consider reading the Java papers and mail archives before suggesting yet the same Java risk.
geoffI think you had it correct when you called this folklore. I have no previous knowledge of this, but it sounds a lot like the stories about poisonous snakes wrapped in imported carpets or burglary victims finding their pet Doberman choking on severed fingers. I believe there have been a book or books published on these types of stories, that everybody has heard of (second hand) but can never be traced to an origin.
Has anybody checked the records of CSU to see if their ever was an instructor by the name of Gerry Johnson?
Think about it. Being good computer people, can we think of any piece of code capable of this? What would it be doing in an IBM 370 MVS operating system written (in the early to mid 1970s?) long before personal computers, and networking as we know it today was not much more than a few isolated experiments? What is "IBM's entire global network"? (Did they invent the Internet long before the U.S. military thought of experimenting?) Just how would one go about "boarding up" a display booth? Most of them can hardly stand up on their own, much less support a load of lumber.
The real risks are bad enough. It doesn't take more than a little thinking to avoid chasing stories about a guy with a big blue ox.
>[I have heard some reports that this flaw is actually an intentional
>feature intended to detect copyright ripoffs.... PGN]
Usually, these inserted flaws are (should be?) in the non-executable portion of a program. Often, a section of code that will never be executed is inserted. To be most effective, this code should, in fact, be unexecutable--containing a zero divide, for example.
The practice stems from a court case, Frank Shepard Co. v. Zachary P. Taylor Pub., Co., 193 F. 991 (2d Cir., 1912). In the case, the publisher of a legal research book (Shepard's citator) inserted lists of citations for cases that did not exist. When 138 of these showed up in a competitor's publication, the court presumed that the second work had copied the first.
Thus, I have no doubt that Excel has "bugs" inserted in it to allow Microsoft to more easily prove code copying. I would be surprised, however, if these bugs were inserted into effective code.
Ralph Clifford, Associate Professor, S. New England School of LawI have no idea whether the "mysterious figure" is really a copyright trap, but you can't rule it out this easily. Have we all forgotten the days of reverse engineering, and "borrowing" code from other programs? Admittedly, doing this for the calculation engine of Excel seems a rather odd pursuit, though.
Another variation comes to mind, though. Has Microsoft ever licensed out source or executable code to other companies. If anyone used the code in a "black box" form, this would be a very simple way to track the licensed
code, and verify it hadn't been distributed improperly.
If Marketry doesn't already have my E-mail address, surely sending them E-mail will ensure that they get it. Given the unrepentant nature of many cybermarketers, I fear that my address would go into their list and my (valid) complaint would go into the bit bucket.
Perhaps we're better off sending their name to the owner of the Blacklist of Internet Advertisers (*)...
(*) http://www.cco.caltech.edu/~cbrown/BL/
Ted Wong <twong@isis.com> Isis Distributed Systems, Inc., Ithaca, New YorkSometime this summer (of '95) I read some IBM literature on their new series of disc drives. The new drives had some very interesting features including "ping"s to check drive health and prevent corruption of data.
The "TravelStar" (I believe that's the name) was their series of notebook computer drives. They had a shock sensor which would alert the drive's onboard controller to delay writes when you drop your notebook. I don't remember the number but recall it being able to sustain a fairly large shock without corrupting data.
The "UltraStar" was described as having audio, vibration, and current sensors installed which were used to detect impending failure of drive components. This feature (in theory) could have come in handy when (at 3am) one of our drives started squealing.
This sounds good in theory, but how does it report the problems? The method of reporting was never mentioned in the literature. One common method is to flash the drive light in some pattern to alert you. Probably not used as most drives don't have LEDs these days (just small footprint connectors specially designed NOT to work with any of the LEDs you have on hand). Besides, most computers have the drives installed internally and the LED on the front of the box shows CONTROLLER activity. If the box is in a data center, it may never be looked at anyway.
The better solution would be to have some SCSI command or inquiry that would return information about the drives health. Now we run into the problem of how do we read it. Most OSs would not have the code to check that information. One could probably write a program which would inquire that information from the drive, if one had a familiarity with SCSI programming.
I've also heard that 4mm DDS tape drives store statistics on read and write errors. Apparently they also have several error correcting modes ranging from none amazing. Yet again, it seems most backup software doesn't worry about this. I'd presume these features would be configurable and/or played up in the literature, but I've not run across any mention of these features in the backup software I've used (no doubt there is some out there though).
But it's the thought that counts... I'm sure I'm not the only one who is running an UPS (at home) without the monitoring connection to the computer hooked up.
The RISK is that the thought isn't enough. A coordinated effort is required for the scheme to work. If you don't get the "lower-order acolytes" to ping your tubes, the pong means nothing.
SeanThis reminds me of a story I heard on BBC Radio a few years ago: at an atomic power station, a safety inspector needed to regularly check certain bolts were done up tight. What better way than to put a spanner on the bolt and give it a tug ? After a few months of weekly inspections like this, bolts started shearing off. It took quite an investigation to find the cause of all those broken bolts.
Mike Wilson, ICL Medical Portfolio, Kings House, Kings Road, Reading, RG1During our session (The Internet and Beyond) at the National Information Systems Security Conference (formerly known as the NCSC Security Conference) in Baltimore last week, Marcus Ranum made a reference in his presentation to `waving a dead chicken
over it' as an analogy to, what I like to call,
Voodoo Technology.
While humorous in context, the content issue is one of risks which are not always readily apparent. Without proper testing and verification, network security products intentioned to provide some level of access control, application proxy service, or other types of security may not be the panacea that it was envisioned.
The comparison is that while product marketing may claim that it is bulletproof, the engineering verification folks may have simply `waved a dead chicken over it' and muttered a few incantations. Take the time to test and verify.
Caveat Emptor.
Paul Ferguson, cisco Systems, Consulting Engineering, Reston, Virginia USA pferguso@cisco.comConcerning the VH-60 (the presidential version of the common UH-60 Black Hawk) that has suspected EMI issues.
In the late 80's, I was involved as a system safety engineer on the UH-60 program and the development of the VH-60 and EMI hardening was a major design requirement. I am familiar with the EMI cases and they have usually involved a nose low attitude at impact with the stabilator in the full down position. What used to happen is that the crews would use certain very high power radio towers (such as Voice of America towers) a way points for navigational reasons and we would see some uncommanded inputs a particular times associated with certain power levels and frequencies. A trained aircraft accident investigator can tell with reasonable certainty, the attitude and stabilator position at impact.
Any radio beam that could cook or burn human flesh is well above the design hardening of ANY aircraft out there flying around, executive use transport or not! This case sounds to be more like an urban legend than a real event!
Howard EtkindIt seems like Mr. Coley's note in RISKS-17.39 on the Marine Corps' helicopter crash is more appropriate for alt.conspiracy. Is it really believable that the US has a giant Star Wars death ray that can microwave troops from 4 miles away and that it accidentally cooked a Presidential helicopter?
I did check carefully to see if the post was made on April 1, but sadly, it was not.
Mark Stalzer, mas@acm.orgWas this story supposed to illustrate the RISKS of EMI? RISKS of believing unlikely stories from the net is more like it.
Coley tells us about a mysterious helicopter crash and subsequent cover-up without offering *any* citations that can be checked. Only one source is quoted by name: the man who "uncovered" the conspiracy.
One passage in particular sent my hoax detector past redline:
> "Those men were burned and there was almost no bleeding
> from their wounds." [...]
Let's see. People were burned, but clothing was unharmed. Sounds like spontaneous human combustion to me.
Craig,
What's your relationship to this story? The reasons why I ask are these:
First: The President does not travel from the White House in Black Hawk helicopters — he uses a rather old Sikorsky version which has been in service since the Vietnam War.
Second: What qualifications does your apparent source, Mr. Owens, have for deciding that a report on the crash is false, since he is not aware of which helicopter model is used by the President?
Third: There appears to be no relation to comp.risks .
So, what's your reasoning?
- Bruce TaylorI have difficulty in seeing how two postings in RISKS-17.39 are relevant to COMP.risks (my emphasis). They are
Presidential Black Hawk Crash (Craig J. Coley)
How to derail a train (Bob Frankston)
Both were moderately interesting, but seem to have nothing to do with risks of using computer-based systems. I suppose that one could infer that computers were used to control or direct the supposed microwave transmitter in the first story. The jumper wire in the Amtrak derailment may have been intended to mislead a computer-based signal system, but the poster seemed more concerned with the publication of "how to" information than with computer-related errors.
While both articles are worthy topics of discussion, if comp.risks is going to stray off-topic into the general risks of living in the industrialized world, it runs a risk itself of becoming unfocused and, eventually, unread.
Rick Simpson, IBM T. J. Watson Research Center, P.O. Box 704, Yorktown Hts,[Besides, it was an OLD story. But the relevance issue has come up repeatedly. This is a forum on risks to the public in computers and RELATED SYSTEMS. Risks of interference are rampant (see my book, Computer-Related Risks, for example), and need to be protected against — even though they are not specifically computer relevant. The death of a pacemaker patient due to interference is clear evidence of that. PGN]
> From the Electronic Telegraph <http://www.telegraph.co.uk/>, 1995-10-10:
> Victim of gas blast sent 3230 pound bill (=A3230), by David Graves
Let me guess. "=A3" is a MIME escape for a pound sign [...], and the bill was really for 230 pounds. Right?
Mind those character sets, folks! This reminds me of the item in comp.dcom.telecom / Telecom Digest a few months back where a statement intending to say that you should "dial `0'" in a certain situation came out as "dial 302".
The latest wrinkle in this is the appearance of mail transport software that detects characters with the high bit set and automatically converts the whole message to MIME format in the hope that this is the safest thing to so — which leads to things like "=A3" turning up in mail between people who have no idea what it means. Until now, a character set mismatch might cause some characters to come out wrong, but at least the number of characters didn't change.
Mark Brader, msb@sq.com SoftQuad Inc., Toronto[Bernard Lyons <bernard_lyons@Claris.COM> mused on the ambiguity of pounds weight vs Pounds Sterling, and suggested using the 3-letter SWIFT codes instead, where Pounds Sterling are GBP, US Dollars are USD, Japanese Yen are JPY, etc.RISKS has POUNDed on this one before. I left the =A3 in because I try to avoid microediting; besides, I might have miscorrected it, which would have resulted in further flames. PGN]
Even worse is a system that does not know that something has gone wrong even when it has.
An example - some of the latest Intel motherboards do ***NOT*** support parity memory at all!
I always felt that parity checking was not enough - I want ECC memory.
Now, if memory goes bad, who knows what will happen?
The recent issue of RISKS had so many items that I wanted to comment on that I just had to write in:
> Subject: Basic Flaws in Internet Security
On average, there are about 5 bugs of similar severity found in the Internet every month. This one was nothing special - in fact, just a special case of known IP spoofing problems throughout the Internet.
> Subject: Pinging the vacuum tubes (Re: Univac episode, Williams, RISKS-17.38)
There is a field called Built-In Self-Test that concentrates on testing components at startup, during operation, and at other times. Every PC I know of does a set of start-up tests.
> Subject: Risks in Java
Risks in Java are being widely discussed on the Internet, and the vast majority of people I interact with find a great deal of risk in it.
> Subject: Effective use of the Internet
So-called spamming is getting more frequent on the Internet. At this point, several mailing list owners are working on anti-spamming software to detect the most simplistic threats. They look at headers in multiple mailing lists and if they match, the messages are blocked until the list manager checks them.
There have also been a recent series of attacks where people use the newsgroup "cancel" command to remove other users' messages from mailing list distributions.
More similar attacks seem certain in the near future.
> Subject: Risk of visiting wrong place on the Web
Junk mail is a legitimate marketing technique. Like it or not, it is going to happen. I have been accused of it myself. The cure is to add integrity to the Internet, something that few of the Internet designers seem to understand these days.
> Subject: Analysis of Human Factors and Outages
There have been several similar studies in the past and several books have been written on how to reduce these things.
> Subject: Re: Microsoft Excel 1.40737488355328
I was creating a simple spreadsheet in Excel for my father-in-law a few months ago and noticed that it failed to copy a cell properly. The cell didn't have 1.40737488355328 in it. Eventually, I abandoned Excel and saved the file in 123 format. When I ran it under 123, it gave the right answers. I haven't used Excel since, and don't plan to ever use it again. If you can't copy or add correctly, you're a pretty poor spreadsheet.
[The 17 Oct 1995 Edupage has an item on the new flaw in the Windows 95 version of Excel 7.0, discovered by a Houston financial consultant, where "a cell linked to a cell in another spreadsheet was not updating its information properly." (*Houston Chronicle*, 14 Oct 1995, C1) PGN]-> See: Info-Sec Heaven at URL http://all.net
I saw their attack in one of the security newsgroups, and I was unimpressed by it. It doesn't report anything new.
People have known for years that NFS was vulnerable to spoofing attacks. This is not news. People have known for years that even the commonly-used authenticated file-service protocols (e.g., Kerberized NFS, AFS) authenticate only the connection without authenticating the file data being sent over it. This is not news.
The solutions to this problem are known and have been for a long time. The easy solution is to install security-related binaries on the local disk instead of on a fileserver. Of course, this blows the diskless workstation model, but I think that was on its way out anyway :-). The hard solution is to fix the file-service protocols to integrity-protect and/or encrypt their data (and to get people to use secure file-service protocols like Kerberized NFS or AFS, instead of relying on tried-and-true insecure NFS). Perhaps some work in that direction will arise from the attack published by Brewer et al, and that would be a good thing to come out of what they published, but otherwise, I don't see much point to it.
(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.)
Please report problems with the web pages to the maintainer