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…
From the Orange County Register, Orange County CA, 3/29/1995 edition, crediting "Register news services":
The article describes in 3 paragraphs the effect on train traffic of a computer crash: "[it] froze passenger and freight trains in their tracks" for 2 hours. 8 states in the Southeast US were affected during Monday (3/ 27) evening rush hour on tracks operated by CSX Transportation. Service was restored "under human direction".
Services that were held up included Amtrak (2100 passengers), Tri-Rail commuters in south Florida (5000 passengers) and freight trains in locations from Louisiana to North Carolina.
[Notes from dps: Most major railroads have reduced the number of dispatching centers, in the trend typical of many modern businesses. For instance, UPRR now operates all dispatching from Omaha, Nebraska, and SPRR from Denver, Colorado. CSX can be assumed to have done the same type of consolidation. Key elements of this move include computer displays to show the status of tracks and traffic flow (replacing specialized "CTC" boards), communiciations equipment (often already in plade, just a new hop). These computers often also show the availability of equipment.
Resuming "under human direction" was probably done by the same dispatcher staff, but using "track warrants" instead of signalling, and with locations of trains tracked by radio rather than by the signalling equipment. This would result in slower speeds and larger separations.
I would be interested in hearing more details of the crash and in the backup procedures.]
/dps (David P. Schneider, Emulex Network Products)There was an article in the Saturday San Francisco Chronicle with the headline, "Police Hunt Slayer of Oakland School Cop." At first glance this appears to be yet another sad tale of inner-city violence with no relation to computer RISKS. However, buried in the middle of the article is the statement, "The source also said that the slain officer was found sitting in his patrol vehicle and may have been using his patrol car computer at the time of the shooting."
Could it be that the visual and mental concentration required to operate a computer can constitute a potentially fatal distraction for a police officer?
Glenn Story story_glenn@tandem.com gstory@netcom.com 70135.756@compuserve.comI heard an item on the BBC radio 4 news last week that set me wondering about stock-control systems. The story described the arrest of an alleged supermarket blackmailer. He was arrested for planting (fake) bombs in supermarkets. The reporter went on to say that he had been caught because the police had been able to trace him as the owner of the shoebox used in one of the fake bombs.
It seems to me that the police must have traced the stock number on the box down the distribution chain using the shoemakers computer systems. Once they determined which shop it was sold from they must have used the shop's stock control system to determine when it was sold. In order for the police to determine who bought the shoes (and the box) the arrestee must have used a means of payment (e.g., credit card) that included his name.
I applaud police actions to catch a blackmailer, and I assume that there is more evidence against him to support their case. But I can't help wondering where all those shoeboxes I threw away are now, and who is doing what with them?
Is there a risk here? It depends on you. If you
On Friday, 7 April 1995, KNOW (the St. Paul, Minnesota, National Public Radio affiliate) reported that a jewelry store in St. Cloud had been burglarized. In order to circumvent the jewelry store's alarm the thief first broke into an adjacent florist's shop. He then used a pickaxe to hack his way through an interior wall into the jewerly store.
He looted the store at his leisure and fled leaving no prints or other evidence behind--except the pickaxe. A sharp-eyed police officer noticed a barcode sticker was still attached to the pickaxe. The officer took the tool to a local hardware store and had the owner scan the code into his register (the reporter did not say if the officer visited multiple hardware stores). Voila! The pickaxe had been sold the day before the burglary. By matching the time of sale as recorded in the register's database to the time stamp on the store's video-surveillance tapes a clear picture of the suspected burglar was obtained. At air time he had not yet been apprehended.
Sean Burns, University of Minnesota/College of Human Ecology, 48 McNeal Hall< Abstracted from The Oregonian, 12 Apr 1995, Section B, page 1 >
Computer software used to track blood supplies in about 250 blood banks has been recalled because of the possibility that it could allow the release of contaminated blood.
Among the problems with the software:
The FDA caught the errors in an inspection of Informedics (which is doing business as Western Star), the Lake Oswego, Oregon company that produces the software.
John Torici, president of Informedics, said that his company has about 250 clients in six countries, "and in the 12 years we've in in the business they've processed literally millions of units of blood and there has never been an incident of bad blood being released as a result of our software"
Other countries don't have our sort system that makes everyone here eager to sue. Is this a good measure of software quality, given the obvious mistakes made above?
Does the FDA use adequate software testing methods?
Paul Szabo Portland, ORIt can be risky to install old software on newer systems.
Among the many problems Microsoft Windows has it the problem of keeping up with the latest device drivers. This problem is especially troublesome for multimedia cards and drivers, which are usually installed in the \WINDOWS\SYSTEM directory. My own system has mostly 1994 versions of system software and drivers (but it is still Windows 3.1).
The other day, I was looking for some trivia information about the "Sound of Music" (did it get an Oscar for best song?), and none of my usual references had the answer. I did have a copy of Microsoft's Cinemania 1992, which I haven't used since I got my current machine. So I thought, OK, simple, I'll just install it to find the answer (No — best songs are for original scripts, not adapted — it did get Best Scoring for Adapted Works).
I got my trivia answer, and things seemed fine, but they weren't. Because multimedia has always been one of the big problem areas of Windows, and the 1992 Cinemania had some drivers that were "better", it seems that it blindly took its "latest" 1992 versions and replaced the existing drivers in the \WINDOWS\SYSTEM directory without taking into account that it might be 1995 now. (It didn't ask for any confirmation - it just overwrote!) So, the next time I booted my system, my sound was broken. It took me a couple of hours to diagnose the problem and get the current drivers reinstalled, and I know what I'm doing — pity the poor new or casual user.
The RISK — don't forget today's news is tomorrow's history. While Microsoft might have been trying to be helpful in 1992, they forgot that someone just might use it in 1995. All very irritating!
Bruce E. Wampler, Ph.D. (wampler@cs.unm.edu)The following was forwarded to me through a mailing list, and I can't even determine with certainty if the signature line at the end is from the author or some intermediate forwarder.
The story is worth the telling, however.
-- JerrySubject: Good software humor: What would you do?
At a software engineering course for aspiring managers the participants are asked: If your team of programmers/analysts implemented airplane control software, and you were flying one day, finding out before take-off that this plane was one of those equipped with YOUR software, how many of you would get out?
All except one person raised their hands. The course instructor asked the only one to have left his hand down "What would you do?"
"Stay in my seat — if my team wrote the software for this plane, it wouldn't move, let alone take off."
Rick Simkin rick@frame.com PHONE: +1 312 2664437Date: 10 Apr 1995 20:49:58 GMT From: graff@liberty.Eng.Sun.COM ( Mark Graff ) Newsgroups: comp.security.unix Subject: About the recent Sun "CWS" mailstorm Last week a great many Sun customers were subjected to a torrent of mail messages which swamped the Customer Warning Mailing list. Since quite a few of those folks also read this newsgroup, I thought I would post this apology and explanation here.
First, quickly, the current status is:
I maintain a mailing list of people interested in receiving Sun Security Bulletins. The list has thousands of addresses on it, some of which are themselves repeater aliases. When I am ready to send out a security bulletin, I (1) produce a mail alias from the mailing list, (2) active the mail alias on my machine, (3) send the mail, and (4) deactivate the alias.
The deactivation step is important. It prevents mailstorms and stops malefactors from probing my machine in an SMTP dialog to obtain a list of bulletin recipients. This step was omitted when we sent out our bulletins last week; so, when a recipient replied, asking to be removed from the list--and cc'ed the "cws@liberty.sun.com" alias--the fuse was lit. When others sent responses to that request to the same mailing list, the mailstorm was launched.
In a second procedural error, the next day, no one who could deactivate the list was watching the traffic. So what would have been an annoyance turned into a real donnybrook. Of course as soon as the right people got the right message the alias was deactivated, stopping the cascade of messages.
The problem was exacerbated by the fact that (appearances to the contrary) I handle list requests manually, as a security measure. One correspondent, not aware of this, sent several dozen "unsubscribe me" messages to the entire list in an attempt to escape the cascade. This resulted in the creation of thousands of additional messages.
I am responsible, and will apologize personally to as many customers as I can. In the meantime, please understand that this was the result of human errors and a good measure of bad luck--not a bad policy, or a lack of interest on our part.
I would also like to express my thanks to the many people who, unaware of the exact nature of the problem, suggested technical solutions. As of this moment I am not planning any changes in the handling of the mailing list, which we operated with no problems for several years before the incident last week. We are of course reviewing alternatives.
-mg- Mark Graff Sun Security CoordinatorWhile writing an article about digital cash, a number of new risks occurred to me. If truly safe, secure, and private digital cash can be created, legitimate businesses will not be the only originations to avoid the problems of transporting large amounts of cash. The classic suitcases full of cash will be replaced by a smart card or credit transfer that will look just like any other. To transfer a few million to an offshore bank, you just make a call. For additional security, multiple transactions might be sent from pay phones, cellular phones, and/or sent through an ever changing list of dummy corporations, forwarded phones, etc. The information could be hidden in legitimate data transfers, or just carried. After all, one smart card will look just like any other, no matter how much money is inside. Or the guts could be removed from the card and hidden nearly anywhere. Spies, etc. will love this new money.
This particular risk will depend to some extent on just how private digital cash becomes. If it is really an advanced debit card system with encryption, privacy will depend on the ability to get a card without supplying large amounts of personal information. If ID is required only the criminals will have privacy. After all they don't mind lying, don't have fixed addresses, and the risks are minor compared to those they normally face. If the card or account numbers are tracked to deal with theft, fraud, etc., then they will be available to the IRS etc. Of course this information will only be available to the "proper" authorities ... and anyone who knows who to bribe. Also since the cards or what ever, will inevitably have an account number, public key, or other identifier, it won't be long before someone starts connecting paid for by account xxxx and sent to address yyy, and there goes privacy.
On the other hand, people are ingenious, and many will be highly motivated. Black market cards and/or accounts will exist. The listed owners might even be real, illegal aliens, little old ladies with nothing to lose, or totally fictitious. When the cards or accounts become international, whole new worlds of villainy open up.
The very definition of a bank may change. Most banking is already an exercise in data processing. Without the need for a vault and tellers, the whole thing might be run from an advanced laptop. The notion of offshore banks might take on a new meaning, when the bank might be mobile, or distributed over large distances and many jurisdictions.
New, unforeseen risks are also inevitable. When paper money replaced coinage, inflation became almost inevitable. Not that many kingdoms or countries could long resist adulterating the coinage, but I know of no paper money that hasn't suffered inflation. One possible example of the new risks involves check float. Entire industries exist to exploit the time between a check being issued and when it clears. What happens when float, and checks, go the way of the Dodo? What happens to the Swiss banking industry if numbered accounts are no longer necessary? What happens to the IRS if everybody effectively has a numbered account?
[Name not included in E-mail. PGN]
A common theme in this forum is how computers can create dismay out of order. For instance, I've always considered FedEx to be far superior to the Post Office because you their computer system tracks the packages to the correct destination. Today's WSJ (April 11, 1995, B1) offers a story describing how lawyers routinely subpoena FedEx for these same computerized shipping records. The article mentions a tobacco researcher who had his FedEx shipments subpoenaed by a tobacco company interested in his correspondence.
Being a curious and frequent customer of Federal Express, I called up their legal department to find out if anyone had been subpoenaing my shipping records. This seemed to upset them because they get 300-500 subpoenas a day and their data base just
wasn't set up to look for my name. They did tell me that they can only offer proof of delivery and copies of the airbills generated from microfiche. These do not arrive overnight, however, because it takes them 2-6 weeks to process each court order. Oh,
they did mention in passing that they don't keep any records of cash transactions.
> Throughout the execution, the computer's systems monitor the current,
> making sure there is no drop in power.
I am aghast — it sounds just like the technology used in ground-fault interruptors, those nifty gadgets that turn off the current if you you drop a plugged-in appliance into the tub with you. But instead, this system keeps the current on until its victim has shunted a sufficiently lethal dose.
I suppose the lesson is that one person will always find a way to use a technology for the exact opposite purpose that another person was designing it for. And I suppose that computer programmers and electricians have already build lots of systems that have already intentionally killed more people than this electric-chair-controller will ever get a chance to do. But dammit, is this what folks had in mind back when they were inventing embedded controller systems, analog-to-digital converters, silicon-controlled rectifiers and the other doodads that this execution system must use?
Ed Ravin eravin@panix.com +1-212-678-5545A previous anonymous poster [in RISKS-17.04] took some heat by calling the authors of the "Satan" security software "amoral". While that point may be arguable, how about another term that is harder to argue: "inept", or perhaps "sloppy"?
Since the original much-heralded release of Satan, CERT has had to send out two bulletins warning of serious bugs in the original version, and in the succeeding version that was supposed to fix the bugs in the first version. In each case, the bugs were of the sort that INTRODUCED security holes where none had existed before. And of course each new version checks to see if it can exploit the security bugs introduced by the previous version--so if you ever stop updating you're really in for a surprise!
It doesn't even appear that the bugs were terribly obscure--it looks more like a rush job with inadequate testing.
Great security software. If you had a secure system before starting to work with Satan, you can end up with an insecure system afterwards. It's difficult to think of a much less desirable scenario.
Such sloppiness in widely distributed software that is supposed to help solve important security problems is hard to rationalize, to put things politely.
The recent discussions of typos in databases, etc. remind me of a problem that I have noticed with the on line catalog for the library at Portland State University. Shortly before I started my Computer Security class last year, I decided to check the library's holdings in the area by using the on line catalog. I was somewhat surprised when a subject search using the subject "computer security" turned up very little. Not even Dorothy Denning's classic book was found. Looking up a few books by author or title and checking the index terms indicated that the appropriate search is "access control." There does not seem to be a way to reindex entries or to add cross references. One wonders how many searches go awry because of counter intuitive search terms.
PSU's catalog system has another interesting "feature." It is impossible to get out of the system. It was apparently designed for dedicated terminals where the notion of termination or disconnection was considered inappropriate and when you connect to it via telnet you must escape to telnet and close the connection when you are done.
John McHughJerry Leichter had a problem finding a book which he did not know the exact author or title. His story shows that a human can perform pattern searching faster then a computer to find the book, but this isn't always the case. The problem with the computer was poor database retrieval.
I had a similar experience years ago at a library looking for a book I had seen for a few moments, but had forgotten the author, title, and catalog number. However, I remembered the first letter of the author's last name and the general subject. When I used the "friendly" public machines at the library to search for the book, I had no luck. Rather than scan books in the relevant section of the library, I went to the computer services department and talked to a friend in the library's computer department.
By accessing the database through a "computerese" interface, I was able to search the entire database for books within a section of the library (by a range of Library of Congress numbers), first letter of the author's last name, and three possible subject keywords.
The computer found two entries matching my request; one was my book.
Risks? The "friendly" interface, while increasing general use among the public, lacks the power of a "computerese" interface. The users' perceptions about the power and ease-of-use of computers and databases become clouded because of an attempt to show them the power of same.
erik kraft NeXT programmer / 3do programmer ekraft@netcom.comEven if you do have the correct information at hand, you are relying upon the competence of the database designer.
A few days ago I tried to order a book. I knew the names of both the authors, the title of the book, and the publisher. The only information I was lacking was the ISBN.
"No problem" I thought, since most of the bookshops here in Cambridge now have access to an online catalogue of all books on sale in the UK.
The shop assistant typed in the correct query (here I should explain that it wasn't her fault since, by looking over her shoulder, I could see that she typed everything correctly). The computer said that there were no matching entries. She then tried widening the search by missing out some of the information.
Even when asked for all books written by either author the system claimed that nothing existed. Since I was certain of the publisher she agreed to phone them. They claimed it didn't exist, although I knew it did since I had reviewed it for a journal. They then found that their paper list didn't correspond to the computer list - it was listed on paper. Given the ISBN we checked again on the bookshop's system. Sure enough, there was the book with all of the details as I had given them.
The book is now on order. However, if we hadn't persisted, the bookshop, and the publisher, and the authors, would have lost a sale.
Failure to order a book may seem an unimportant problem, but it made both me and colleagues wonder how many relational databases aren't, and what are the consequences.
MarkPlease report problems with the web pages to the maintainer